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

Question

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

В качестве примера, существует хранимая процедура ОБНОВЛЕНИЯ длиной ~ 500 строк и содержит большое количество условной логики, ссылающейся на несколько таблиц и UDF.Процедура принимает обновляемое имя поля и новое значение, устанавливает набор объявленных переменных, выполняет набор проверок и создает динамический оператор SQL для выполнения обновления.Один раз размер подходит всем.Это большое и запутанное дело.

Я хотел бы перенести бизнес-логику на .СЕТЕВУЮ сторону, чтобы упростить управление / обновление, тестирование и передачу под контроль исходного кода.

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

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

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

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

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

Answer 1

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

• Шаблон ActiveRecord - Логика сохранения находится в вашем доменном объекте.
• Шаблон репозитория - Отдельный объект или слой обрабатывает доступ к данным - ваша концепция "прокси" решает эту проблему.

Хитрость с обоими объектами заключается в следующем знание того, когда следует обращаться к базе данных, а когда нет.Например, там будет избыточные проверки, которые будут выполняться между базой данных и доменным уровнем, например, еще до того, как вы выполните вызов базы данных, вы должны оценить наличие ненулевых значений, обрезать строки до длины и т.д.Только после выполнения этих проверок следует выполнить вызов функции Сохранения в базе данных.

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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