Пытаюсь реализовать архитектуру работы с БД (.NET + nHibernate). Не совсем понятно что является бизнес логикой и как правильно ее описывать.
Пусть у нас есть сущность Product у которой есть поле Foo. Сущность, репозиторий (обращение к БД со всеми операциями) описаны в отдельной сборке DBLayer (DBLayer.Entities.Product, DBLayer.Repositories.ProductRepository) (model).
Также есть сборка BusinessLogic (controller). Пусть нам нужно изменить у объекта значение поля Foo, базируясь на логике завязанной на анализе других полей Product (нет, выносить на сторону БД эту логику не получится).
Мы можем:
1. Реализовать в BusinessLogic отдельный класс (не унаследованный ни от кого), к примеру BusinessLogic.ProductLogic и в нем реализовать данную функциональность вызывая при необходимости методы репозитория (DBLayer.Repositories.ProductRepository). Мне не нравится этот подход тем, что по-сути у нас получается очень много связей между бизнес-логикой и сборкой по работе с БД. Хотя, вроде как это правильный подход в MVC.
2. Реализовать в BusinessLogic класс, унаследованный от DBLayer.Repositories.ProductRepository и дописать нужный метод. Возникает вопрос, а можно ли и где прячутся грабли?
3. Внести нужный нам метод в класс DBLayer.Repositories.ProductRepository без реализации дополнительных классов в BusinessLogic. Ок, а как тогда быть, если у нас этот метод будет завязан, к примеру, не только на полях данной сущности? Получается много бизнес-логики переходит в model.

Помогите определится.

Здравствуйте, <Аноним>, Вы писали:

А>Пытаюсь реализовать архитектуру работы с БД (.NET + nHibernate). Не совсем понятно что является бизнес логикой и как правильно ее описывать.
А>Пусть у нас есть сущность Product у которой есть поле Foo. Сущность, репозиторий (обращение к БД со всеми операциями) описаны в отдельной сборке DBLayer (DBLayer.Entities.Product, DBLayer.Repositories.ProductRepository) (model).
MVC описывает только разделение приложения на три компоненты, соответственно, три разных логики.

1. Бизнес-логика, логика предметной области(домена) — модель.
   
2. Логика взаимодействия располагается в контроллере.
   
3. Логика пользовательского интерфейса в представлении.

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

Если под MVC подразумевается реализация в ASP.NET, то подробнее см. в статье: http://msdn.microsoft.com/en-us/library/dd381412.aspx.

А>Также есть сборка BusinessLogic (controller). Пусть нам нужно изменить у объекта значение поля Foo, базируясь на логике завязанной на анализе других полей Product (нет, выносить на сторону БД эту логику не получится).
Еще раз, контроллер — это не есть бизнес-логика, см. выше. Его задача: обработать пользовательский запрос, разрешить модель, передать ей команду, а по завершению выбрать представление для ответной реакции пользователю.

А>Мы можем:
А>1. Реализовать в BusinessLogic отдельный класс (не унаследованный ни от кого), к примеру BusinessLogic.ProductLogic и в нем реализовать данную функциональность вызывая при необходимости методы репозитория (DBLayer.Repositories.ProductRepository). Мне не нравится этот подход тем, что по-сути у нас получается очень много связей между бизнес-логикой и сборкой по работе с БД. Хотя, вроде как это правильный подход в MVC.
Это не "правильный подход MVC", MVC про DAL по уму ничего не знает. Это просто подход, при котором объекты предметной области умеют получать и сохранять свое состояние где-то/откуда-то. Разумеется, связь между предметной областью и логикой работы с хранилищем может быть прямая, что в этом страшного?

Если логика не сложная (и не предполагается усложнение в будущем), то можно и в модели реализовать: NHibernate для того rich model и поддерживает. Здесь пример такого подхода, который вы описали: http://stackoverflow.com/questions/235233/asp-net-mvc-should-business-logic-exist-in-controllers.

А>2. Реализовать в BusinessLogic класс, унаследованный от DBLayer.Repositories.ProductRepository и дописать нужный метод. Возникает вопрос, а можно ли и где прячутся грабли?
А>3. Внести нужный нам метод в класс DBLayer.Repositories.ProductRepository без реализации дополнительных классов в BusinessLogic. Ок, а как тогда быть, если у нас этот метод будет завязан, к примеру, не только на полях данной сущности? Получается много бизнес-логики переходит в model.
2-3: так можно и в хранимую процедуру в базе все засунуть, так грабли станут очевиднее.

А>Помогите определится.
Прежде всего определитесь с разными "логиками": логика взаимодействия с пользователем, логика интерфейса, логика предметной области, логика уровня доступа к данным.