Какая стратегия доступа к данным для большого приложения

Question

Я собираюсь переписать приложение 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, нужно ли этим решениям довести весь список до клиента и найти нужную мне строку?

Итак, каков консенсус в отношении стратегии доступа к данным для приложения с большой областью данных?

Answer 1

Я собираюсь сыграть адвоката дьявола и порекомендовать вам хотя бы подумать о соблюдении хранимых процедур. Они представляют собой фрагмент кода, который вам не нужно переписывать и отлаживать. Эта статья от нашего очень собственного [тм] Джоэла Спольски приводит последовательный аргумент в пользу избежания полной перезаписи.

Учитывая проект «с нуля», вы можете использовать то, что вы хотите, и O / R Mapper вполне может быть хорошим выбором. Тем не менее, вы уже заявили, что приложение VB6 хорошо написано. Если sprocs хорошо написан, то вы получаете часть своего приложения бесплатно, и оно уже отлажено, плюс вы можете переработать схему базы данных и избежать большинства проблем при переносе данных.

Шаблоны Архитектуры корпоративных приложений * Фаулера должны дать вам несколько хороших указателей для проектирования слоя доступа к данным, который будет хорошо играть с хранимыми процедурами, не вызывая проблем с обслуживанием.

Это делается довольно часто в приложениях Oracle / Java. Многие устаревшие приложения Oracle имеют большой объем кода хранимых процедур на PL / SQL - это была стандартная архитектура еще во времена клиент-сервер Oracle Forms. Обычной практикой является написание оболочки для sprocs в Java и создание пользовательского интерфейса поверх оболочки.

Один из других авторов упомянул, что Subsonic может создавать оболочки для звездочек.

Давным-давно у меня была возможность взломать словарь данных, который сгенерировал проверочную концепцию Java / JDBC-обертку для sprocs PL / SQL - IIRC это заняло всего один день или около того. Учитывая, что это не так сложно сделать, я был бы удивлен, обнаружив, что нет ничего особенного в том, что вы можете сделать с полки, чтобы сделать это. В крайнем случае, написать свой собственный тоже не так уж сложно.

Answer 2

Я не могу говорить о Linq-to-SQL, Entity Framework или NHibernate, но я влюблен в SubSonic. Мой опыт работы с ним был исключительно положительным.

Как правило, эти инструменты работают так, что они создают для вас параметризованные запросы в управляемом коде, инкапсулируют этот доступ в классы, а затем предоставляют эти классы вашим приложениям. Полностью сгенерированный DAL-рок.

Используя параметризованные запросы, ваша забота о том, что они могут «довести весь список до клиента и найти нужную мне строку», обрабатывается. Они поддерживают where предложения и другие фильтры, чтобы получить только те строки, которые вам нужны. Вы можете сделать эквивалент select * from foo, но вы не застряли в этом режиме.

Тем не менее, SubSonic - когда используется из коробки для прямого доступа к таблице / представлению - сбивает целые строки, что может быть недостатком в некоторых сценариях. Тем не менее, ваш доступ через сохраненные протоколы не является проблемой - я не могу говорить с другими, но SubSonic услужливо создает класс SPs, инкапсулирующий все ваши процессы, позволяя вам вызывать их как методы и возвращая соответствующий DataTable s, которые затем можно анализировать вручную при необходимости. Существуют также способы инициализации списков классов DAL от procs, поэтому, если proc возвращает набор данных, который напрямую соответствует таблице / представлению, вы все равно можете иметь более чистый синтаксис без ручной обработки.

(SubSonic, между прочим, вылечил меня от «процедур для всего». Сейчас я, как правило, почти не трачу времени на CRUD-процессы, как это делал в прошлом, и использую их только для сложных отчетов. Но ваши пробег может меняться и будет меняться.)

Answer 3

Если запросы выполняются в хранимых процедурах, есть очень хороший шанс, что они уже были хорошо оптимизированы. И, вероятно, они свободно используют выражения SQL для JOINS, подзапросов и т. Д.

Дублирование такого рода эффективности и выразительности, точно , со слоем абстракции типа ORM, я ожидаю, будет проблемой - особенно если вы не совсем знакомы с инструментами.

Вы всегда можете выполнить рефакторинг запросов после того, как получите остальную часть приложения. И мир ORM меняется достаточно быстро, поэтому, когда вы туда доберетесь, варианты, безусловно, будут другими.

Answer 4

Мы пытались использовать сущностный каркас в качестве формы и столкнулись с множеством проблем при попытке использовать его с разработкой на основе домена. У Linq to Sql также есть некоторые ограничения, и Microsoft, по-моему, перестанет поддерживать его в следующем выпуске.

Answer 5

Я бы порекомендовал использовать SubSonic для генерации всего кода для доступа к вашим существующим хранимым процессам, таким образом вы уменьшаете шансы регрессии из-за нового уровня доступа к данным. Затем к любым новым функциям можно получить доступ с помощью классов ActiveRecord, созданных SubSonic. Мне кажется, это самый безопасный и быстрый подход,

Я не согласен с рекомендацией NHibernate, потому что она не очень подходит для работы с хранимыми процедурами.

Answer 6

SubSonic, даже по словам Роба Коннери, одного из авторов, написан больше для поддержки быстрой разработки приложений, а не для больших приложений. Я бы сказал, что вы можете использовать NHibernate, поскольку вы найдете наибольшую поддержку со стороны сообщества, а также проверенные и проверенные фреймворки. На сайте www.dimecasts.net вы можете получить полезную информацию о настройке вашего NHibernate.