Где указать бизнес-правила при использовании Entity Framework

Question

Я немного растерялся.

У меня есть отношение один-ко-многим между Project и Task и другое между Task и TaskEvent.

Задача существует только в контексте Проекта, и, будучи назначенным для Проекта, нельзя изменить ее на принадлежность другому Проекту.

Бизнес-правило гласит, что Задача может быть удалена и, следовательно, удалена из коллекции Задач, которые принадлежат определенному проекту, если у Задачи нет захваченных TaskEvents.

Как мне указать это в Entity Framework? Я использую объекты самообследования, но на самом деле я не знаю, где вообще следует определять правила такого типа. У нас есть другие правила, которые не знают БД, но как определить бизнес-правило, предпочтительно существующее отдельно от классов сущностей по мере их регенерации, как собственный класс с единственной ответственностью?

Я думаю, мне придется реализовать какой-нибудь валидатор, который может использовать отражение, чтобы подобрать эти классы «правил» на основе типа проверяемого объекта, а затем заставить каждого из них выполнять свою валидацию.

Но как мне вставить контекст объекта в это? Должен ли мой валидатор иметь экземпляр контекста объекта и затем передавать его каждому правилу при его выполнении?

И еще больше волнений, как я могу обнаружить удаления? Придется ли мне вызывать старую версию Проекта и сравнивать старые и текущие задачи, а затем проверять все удаленные, чтобы убедиться, что они не записаны в TimeEvents?

Каковы недостатки этого метода и что еще вы можете предложить?

РЕДАКТИРОВАТЬ: я должен указать, что мы используем n-уровневый дизайн, и оба клиентских приложения (MVC и Silverlight) обращаются к службам WCF, чтобы сделать что-нибудь полезное. Это, очевидно, тот уровень, на котором мы хотим реализовать валидацию, хотя, если бы мы могли использовать те правила, которые не специфичны для БД на клиентах, это было бы здорово. В настоящее время мы используем DataAnnotations для этих проверок.

Спасибо

Answer 1

В итоге мы использовали сервисный уровень, который инкапсулировал правила и проверенные сущности на основе контекстов правил.

Для каждого действия существовал контекст и набор правил, которые были связаны с использованием атрибута.Поэтому все связанные правила могут быть нацелены на объект определенного типа, требуемый действием службы.

Правила были идентифицированы с использованием отражения и проверены на вызове службы.

Объекты Entity Framework по-прежнему действовали какнемного более тонкая модель предметной области, чем мне бы хотелось, но мы никогда не сталкивались с серьезными проблемами, и отслеживание, предоставляемое EF, фактически помогло упростить некоторые ранее невозможные правила.

Answer 2

Взгляните на this .

Поскольку вы используете n-уровневый дизайн, я предлагаю использовать EF в качестве слоя ORM, а не полную замену модели домена,Вам следует создать отдельный слой BLL, содержащий бизнес-правила и сопоставить модель домена с классами EF.Если сопоставление не сложное, это можно сделать вручную, иначе вы можете использовать такие инструменты, как Automapper , чтобы выполнить сопоставление для вас.