Добрые люди из СО,
Сегодня у меня есть серьезные опасения по поводу дизайна моего бизнес-уровня. Он основан на объектах Entity POCO, и я хочу добавить логику к этим объектам, НО есть 2 типа логики:
- Чистая логика C#
- Логика сохранения (LinqToEntities в моем случае)
Мой вопрос прост:
Как мне разделить эти два вида?
Во-первых, я думал о добавлении этих двух методов к сущностям. И использовать частичные классы для их разделения.
Во-вторых, я подумал, что мне не нужен перегруженный объект с МНОЖЕСТВОМ методов. Так что, может быть, почему бы не использовать статические классы или синглтоны с методами, выполняющими функции LinqToEntities, и оставить чистый C# в методах сущностей. Затем у меня было бы несколько классов, сгруппированных по функциональному признаку, обеспечивающих логику, сущность передается в качестве аргумента методам классов.
Меня это очень беспокоит, потому что второе решение кажется чище, но похоже, что оно ломает объектно-ориентированную парадигму. С другой стороны, первый кажется анти-шаблоном.
Как вы думаете ? У вас есть яркое решение, разрешающее этот парадокс?
Шизофреническое редактирование: на самом деле то, что я называю логикой постоянства, должно идти в DAL, а чистая логика C# — в BLL. Сущности POCO создаются DAL. Затем я могу расширить эти объекты в своем BLL, чтобы добавить методы. В моем DAL я должен структурировать логику, представленную во втором решении.
