Как я должен разделить сущности методами?

Question

Добрые люди СО,

Сегодня у меня есть серьезные опасения по поводу дизайна бизнес-уровня. Он основан на объектах Entity POCO и Я хочу добавить логику к этим сущностям, НО, есть 2 типа логики:

1. Чистая логика C #
2. логика персистентности (в моем случае LinqToEntities)

Мой вопрос прост:

Как мне разделить эти два вида?

Во-первых, я думал о добавлении этих двух в качестве методов к сущностям. И используя частичные классы , чтобы разделить их.

Во-вторых, я подумал, что не хотел бы объект с избыточным весом с МНОЖЕСТВОМ методов. Так что, может быть, почему бы не статические классы или синглтон с методами, выполняющими вещи LinqToEntities, и оставить чистый C # в методах сущностей. Тогда у меня было бы несколько классов, сгруппированных по функциональности, обеспечивающей логику , сущность передается в качестве аргумента методам классов.

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

Что ты думаешь? У вас есть яркое решение, решающее этот парадокс?

Шизофреническое редактирование : на самом деле то, что я называю логикой постоянства, должно идти к DAL и чистой логике c # в BLL. POCO объекты производятся DAL. Затем я могу расширить эти объекты в моем BLL, чтобы добавить методы. В моем DAL я должен структурировать логику, представленную во втором решении.

Answer 1

Логика, которая описывает, как объект должен быть сохранен / загружен, не принадлежит самому объекту; скорее всего это будет роль службы персистентности, объекта доступа к данным и т. д.

Я бы позволил объектно-ориентированной логике в объекте - мы здесь говорим о поведении объекта, а затем создал бы сервис, который обрабатывает проблемы постоянства для этого типа объекта.