Какая стратегия доступа к данным для большого приложения
Я собираюсь приступить к переписыванию приложения VB6 в.NET 3.5sp1. Приложение VB6 довольно хорошо написано, а уровень данных полностью основан на хранимых процедурах. Я хотел бы пойти с чем-то автоматизированным, как Linq2SQL/Entity Framework/NHibernate/SubSonic. По общему признанию, я не использовал ни один из этих инструментов ни в чем кроме одноразовых проектов.
Потенциальная проблема, с которой я боюсь столкнуться со всеми этими выборами, - это скорость. Например, сейчас, чтобы извлечь одну строку (или весь список), я использую следующий sproc:
ALTER PROCEDURE [dbo].[lst_Customers]
@intID INT = NULL
,@chvName VARCHAR(100) = NULL
AS
SELECT Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name
Чтобы получить одну строку в Linq2SQL/Entity Framework/NHibernate/SubSonic, нужно ли этим решениям довести весь список до клиента и найти нужную мне строку?
Итак, каков консенсус в отношении стратегии доступа к данным для приложения с большой областью данных?
6 ответов
Я собираюсь сыграть адвоката дьявола и порекомендовать вам хотя бы подумать о соблюдении хранимых процедур. Они представляют собой фрагмент кода, который вам не нужно переписывать и отлаживать. В этой статье от нашего очень собственного [tm] Джоэла Спольски приводятся четкие аргументы в пользу избежания полной переписывания.
Имея проект "с нуля", вы можете использовать то, что вы хотите, и O/R Mapper вполне может быть хорошим выбором. Тем не менее, вы уже заявили, что приложение VB6 хорошо написано. Если sprocs хорошо написан, то вы получаете часть своего приложения бесплатно, и оно уже отлажено, плюс вы можете переработать схему базы данных и избежать большинства проблем при переносе данных.
Шаблоны корпоративной прикладной архитектуры Фаулера должны дать вам несколько хороших указателей для разработки слоя доступа к данным, который будет хорошо играть с хранимыми процедурами, не вызывая проблем с обслуживанием.
Это делается довольно часто в приложениях Oracle/Java. Многие устаревшие приложения Oracle имеют большой объем кода хранимых процедур на PL/SQL - это была стандартная архитектура еще во времена клиент-сервер Oracle Forms. Обычной практикой является написание оболочки для sprocs в Java и создание пользовательского интерфейса поверх оболочки.
Один из других авторов упомянул, что Subsonic может создавать оболочки для звездочек.
Однажды у меня была возможность взломать словарь данных, который сгенерировал проверочную концепцию Java/JDBC-обертку для sprocs PL/SQL - IIRC это заняло всего один день или около того. Учитывая, что это не так сложно сделать, я был бы удивлен, обнаружив, что нет ничего особенного в том, что вы можете сделать с полки, чтобы сделать это. В крайнем случае, написание собственного тоже не так сложно.
Я не могу говорить о Linq-to-SQL, Entity Framework или NHibernate, но я влюблен в SubSonic. Мой опыт с этим был в целом положительным.
Как правило, эти инструменты работают так, что они создают для вас параметризованные запросы в управляемом коде, инкапсулируют этот доступ в классы, а затем предоставляют эти классы вашим приложениям. Полностью сгенерированный DAL-рок.
Используя параметризованные запросы, ваша забота о том, что они могут "довести весь список до клиента и найти нужную мне строку", обрабатывается. Они поддерживают where пункты и другая фильтрация, чтобы получить только те строки, которые вам нужны. Вы можете сделать эквивалент select * from foo, но вы не застряли в этом режиме.
Тем не менее, SubSonic - когда используется из коробки для прямого доступа к таблице / представлению - сбивает целые строки, что может быть недостатком в некоторых сценариях. Тем не менее, ваш доступ с помощью сохраненных процедур не является проблемой - я не могу говорить с другими, но SubSonic услужливо создает SPs класс, инкапсулирующий все ваши процессы, позволяющий вам вызывать их как методы и возвращающий соответствующий DataTables, которые затем можно анализировать вручную при необходимости. Существуют также способы инициализации списков классов DAL от procs, поэтому, если proc возвращает набор данных, который напрямую соответствует таблице / представлению, вы все равно можете иметь более чистый синтаксис без ручной обработки.
(Кстати, SubSonic вылечил меня от "процедур для всего". Сейчас я, как правило, почти не трачу времени на CRUD-процессы, как это делал в прошлом, и использую их только для сложных отчетов. Но ваш пробег может, а по факту будет, меняться.)
Мы попытались использовать сущностную инфраструктуру как форму и столкнулись с множеством проблем, когда пытались использовать ее в рамках разработки, управляемой доменом. У Linq to Sql также есть некоторые ограничения, и Microsoft, по-моему, перестанет поддерживать его в следующем выпуске.
Я бы порекомендовал использовать SubSonic для генерации всего кода для доступа к вашим существующим хранимым процессам, таким образом вы уменьшаете шансы регрессии из-за нового уровня доступа к данным. Затем к любым новым функциям можно получить доступ с помощью классов ActiveRecord, созданных SubSonic. Мне кажется, это самый безопасный и быстрый подход,
Я не согласен с рекомендацией NHibernate, потому что она не очень подходит для работы с хранимыми процедурами.
Если запросы находятся в хранимых процедурах, есть довольно хороший шанс, что они уже были хорошо оптимизированы. И, вероятно, они свободно используют выражения SQL для JOINS, подзапросов и т. Д.
Дублирование такого рода эффективности и выразительности, точно, со слоем абстракции типа ORM, я ожидаю, будет проблемой, особенно если вы не совсем знакомы с инструментами.
Вы всегда можете выполнить рефакторинг запросов после того, как получите остальную часть приложения. И мир ORM меняется достаточно быстро, поэтому варианты, безусловно, будут отличаться, когда вы туда доберетесь.
SubSonic, даже по словам Роба Коннери, одного из авторов, написан больше для поддержки быстрой разработки приложений, а не для больших приложений. Я бы сказал, что вы можете использовать NHibernate, поскольку вы найдете наибольшую поддержку со стороны сообщества, а также проверенные и проверенные фреймворки. Вы можете получить полезную информацию от www.dimecasts.net о настройке вашего NHibernate.