Классическое деление MVC приложения на DAL BLL UI предполагает что, DAL и BLL находятся в разных сборках и DAL ничего не должен знать о бизнес логике.
Прошу прощения за наивные вопросы. Но такое деление как мне кажется создает множество неудобств , а преимущества от него не очевидны.
Преимущества :
- Посмотрев на класс в DAL сразу понятно, что сохраняется в базу.
- Соблюдение принципа единой ответственности .
Недостатки:
- Сложно организовать наследование.
- Валидация бизнес логики через атрибуты средствами Entity невозможна.
- Неоправданное усложнение кода.
Буду очень признательна если кто ни будь поможет решить ниже заданные вопросы просто и элегантно что бы и овцы были целы и волки сыты.
- 1 ) Я хочу валидировать Entity через атрибуты в том числе кастомные которые затрагивают бизнес логику. Есть ли способ валидации без смешивания слоев?
- 2 ) Я хочу иметь базовый класс BusinessObject обладающий общими для всех бизнес объектов свойствами и методами. На мой взгляд логично было бы что бы все Entity наследовались от него. Как правильно организовать код?
- 3 ) По сути развитие предыдущего вопроса. Я имею общий базовый класс для некой категории бизнес объектов например BaseAgree. Он должен содержать базовую бизнес логику для всех договоров (в том числе базовые свойства). Вопрос тот же.
*Ps : по моему класс наследник DBContext и является классом ответственным за сохранение в базу. То что в ему передается именно бизнес объект не является нарушением каких то там правил.
Как не старалась не смогла заставить DBContext работать через интерфейсы то есть такая конструкция не заработала
DbSet SomeEntities { get; } *