рамки сущностей POCO + рекомендуемые шаблоны

Question

Нам очень нравится EntityFramework (CTP5), и мы используем его вместе с ASP.NET MVC3.

Что мне не нравится;все перемешано.

Я могу поместить DisplayAttribute , RequiredAttribute , RangeAttribute , CompareAttribute вместе втот же класс, который означает, что я смешиваюсь в проверке базы данных , некоторых бизнес-логике и UI в целом.Я даже могу поместить атрибут ScriptIgnore , чтобы настроить его как объект Json DTO .Таким образом, я могу использовать тот же класс POCO для Persistance, Presentation, DTO и Business Object, а также в качестве моей модели Domian.

Каким шаблонам проектирования вы следуете вместе с набором инструментов EF POCO + MVC3.Какие слои у вас есть?Какие обязанности вы добавляете к своим классам (Является ли ваш класс POCO вашей моделью предметной области)

Answer 1

Я использую View Models для решения этой проблемы. Атрибуты валидации и представления пользовательского интерфейса переходят к модели представления. В этом шаблоне контроллер использует хранилище для извлечения модели EF, сопоставляет эту модель EF с моделью представления (для этого я использую AutoMapper ) и передает модель представления в представление. Поскольку модель представления содержит все атрибуты представления пользовательского интерфейса, представление ведет себя как ожидалось. Каждое представление должно иметь свою собственную модель представления. Это означает, что вы можете иметь несколько моделей представлений, связанных с одной и той же моделью EF, но содержать другое подмножество свойств и атрибутов форматирования отображения на основе конкретных требований представления.

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

Answer 2

Мои классы POCO почти всегда являются моделями доменов и почти никогда не рассматривают модели, поэтому у меня нет этих проблем.

Лучше всего использовать специальный класс "модель представления" при передаче данных из контроллера в представление(или как JsonResult).В этом случае вы помечаете атрибуты на основе пользовательского интерфейса в этой модели представления.В большинстве случаев (за исключением приложений с чисто грубым интерфейсом) вам необходимо отображать нечто большее или меньшее, чем ваш доменный объект, поэтому вам все еще нужна некоторая модель представления (если вы не используете ViewData напрямую).

Примечания к данным по объекту домена имеют смыслтолько если вы хотите использовать их для проверки на уровне бизнеса / данных, которая может принимать другие правила, чем проверка пользовательского интерфейса.

Если вы хотите следовать строгому DDD, где классы POCO являются объектами домена = предлагает методы, выполняющие логику домена в случаеОбъект, который вы должны пойти еще дальше, потому что в этом случае ваша деловая сторона не должна выставлять объекты домена для контроллера.В этом случае вы получите объекты для передачи данных, которые отображаются на бизнес-фасаде и используются контроллером.Я не пурист, поэтому в этом сценарии я склонен к непосредственному использованию аннотаций данных в DTO, но это зависит от других требований.