Куда перемещать бизнес-логику при ее перемещении из базы данных

Question

У меня CRUD-тяжелое приложение ASP.NET со всей бизнес-логикой в ​​хранимых процедурах.

Например, есть хранимая процедура UPDATE длиной ~ 500 строк, которая содержит большое количество условной логики, ссылающейся на несколько таблиц и пользовательских функций. Proc принимает обновленное имя поля и новое значение, устанавливает набор объявленных переменных, выполняет проверку и создает динамический оператор SQL для выполнения обновления. Как только размер подходит всем. Это большой и запутанный.

Я бы хотел перенести бизнес-логику на сторону .NET, чтобы упростить управление / обновление, тестирование и управление исходным кодом.

У меня такой вопрос: куда должна идти эта бизнес-логика?

Допустим, у меня есть объект PurchaseOrder со свойством с именем 'Factory'. Если Фабрика изменяется, мне нужно убедиться, что назначенный новый завод делает продукт, который находится в Закупочном заказе, что у него есть ценообразование, и что минимальное количество запрашивается на основе этой фабрики и т. Д. Все эти проверки требуют запросов в базы данных.

Должен ли я, чтобы установщик Factory объекта PurchaseOrder отвечал за проверку данных через метод / свойство isFactoryValid, которое выполняет множественные вызовы универсального объекта доступа к данным, а затем выполняет обновление, если оно есть?

Или я создаю объект-посредник PurchaseOrder / Database, который отвечает за обработку только доступа к данным, связанным с PurchaseOrder. В этом случае у меня будет метод isFactoryValid в прокси, который вызывается установщиком PurchaseOrder, а затем вызывается метод обновления прокси?

Как определить, нужно ли мне беспокоиться об увеличении трафика в базе данных со всеми этими дополнительными вызовами?

Answer 1

Один из способов сделать это: У вас есть уровень данных в .net (один или несколько классов данных) с интерфейсом для уровня ... затем у вас есть бизнес-уровень, который выполняет бизнес-логику с использованием интерфейса. http://en.wikipedia.org/wiki/Multitier_architecture

Answer 2

Существует два основных шаблона, которые широко используются для реализации логики персистентности из БД:

• Шаблон ActiveRecord - логика персистентности в вашем доменном объекте.
• Шаблон репозитория - Доступ к данным обрабатывается отдельным объектом или слоем - ваша концепция «прокси» решает эту проблему.

Уловка с обоими объектами - это , зная, когда совершить поездку в базу данных, и зная, когда нет . Например, будет избыточными проверками, которые будут выполняться между БД и уровнем домена, например, даже перед тем, как вы сделаете вызов БД, вы должны оценить ненулевые значения, усечь строки до длины и т. Д. Только после того, как будут выполнены эти проверки, должен быть сделан вызов Save в db.

Существует также широкий спектр стратегий, позволяющих повысить производительность или минимизировать количество обращений к базе данных, таких как отложенная загрузка, транзакции и т. П.

Answer 3

Это будет зависеть от созданной вами объектной модели и от того, как вы позволите своему вызывающему абоненту решить, какая фабрика будет новой фабрикой для обработки PurchaseOrder.

Например, если вы предоставляете вызывающему абоненту список фабрик, из которых он может выбрать, вы можете отфильтровать список только для тех, которые поддерживают продукт, связанный с существующим приобретением (я предполагаю, что вы редактировали существующий заказ). , Если вы хотите, чтобы PurchaseOrder проверял, что Фабрика может обработать заказ, я бы попросил установщика на PurchaseOrder вызвать метод на Фабрике (что-то вроде CanProcessOrderFor (product, amount)).

Я предполагаю, что вам уже нужно было выполнить запрос к базе данных, чтобы получить список фабрик и PurchaseOrder. Я бы попросил объекты Factory вернуть их список поддерживаемых продуктов и текущих количеств (или минимального заказа - какой бы ни была ваша логика).

Хороший ORM, такой как NHibernate, позволит вам кэшировать некоторые из этих результатов, чтобы минимизировать количество обращений, если это распространенный сценарий.

Answer 4

Посмотрите на Domain Driven Design (DDD), который ответит на многие ваши вопросы. В нем говорится о репозиториях для доступа к данным и спецификации для проверок. Хорошая ORM также поможет. Эта книга тоже великолепна:

альтернативный текст http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg

Answer 5

Вы также можете преобразовать свою бизнес-логику в куски многократно используемых веб-сервисов. WCF обеспечивает отличную поддержку инструментов.