Пытаюсь реализовать архитектуру работы с БД (.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.

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