Где разместить логику приложения при использовании Entity Framework и MVVM

Question

В последние дни я потратил много времени на создание архитектуры для своей программы, но все еще имею к ней проблему. На данный момент это выглядит следующим образом:

• DataLayer: Вот мой контекст класс, который получен из DbContext и классов Mapper которые, полученных из EntityTypeConfiguration как JobMap для объектов домена находятся
• DomainLayer: Здесь мои объекты домена/бизнеса, такие как Работа или Расписание проживает.
• Presentation Layer: Здесь у меня есть * ViewModel и * Просмотр классов (я использую WPF для просмотров)

Теперь мой вопрос: Я хочу создать приложение для планирования с некоторыми возможностями оптимизации (его это однопользовательское и однопользовательское приложение, поэтому дальнейшее развязывание, такое как веб-приложение, не требуется). Но у меня есть проблема, что я не знаю, где это приложение вписывается в эту архитектуру?

Учитывая следующий пример использования: пользователь нажимает кнопку «Пуск» в представлении, который вызывает ViewModel, который перенаправляет на мое приложение для планирования/оптимизации. Затем это приложение получает все новые задания из базы данных и создает/обновляет текущее расписание. Затем ViewModel должен обновить старое расписание новым. Наконец, в представлении отображается сгенерированное расписание для пользователя. В этом случае мой ViewModel знает о моем приложении (потому что он его вызывает) и о моих доменах/бизнес-объектах (потому что мое приложение будет доставлять, например, объект домена, который инкапсулирует ViewModel).

Правильно ли это использование EF, MVVM и моего приложения?

С уважением

Answer 1

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

Вот как вы смотрите на это в вашем примере:

• Ваше представление слой (PL) получает сообщение через кнопку пуска.
• PL вызывает домен и сообщает ему, чтобы создать расписание. Этот вызов, вероятно, относится к службе домена.
• Затем ваша служба домена отвечает за заполнение объектов домена Job, создание нового объекта домена расписания (или изменение существующего) и возврат объекта домена Schedule.
• Ваша PL тогда просто отображает возвращенный График.

Это может быть иначе, если вы просто хотите получить существующий объект Schedule. Вместо вызова службы домена вы попросите репозиторий домена получить существующее расписание. Репозиторий будет способом инкапсуляции или иным образом затенения слоя данных из вашего PL и вашего домена.

Теперь, что вы НЕ хотите сделать:

• Не получить список заданий в вашем PL, а затем использовать этот список заданий для создания расписания в контроллере вашего MVVM. Это будет бизнес-логика, которая определяет ваш домен.
• Если расписания обычно генерируются из рабочих мест, независимо от того, вызывается ли он из MVVM или сайта PHP, то не добавляйте сложности в PL и Domain Layer, заставляя PL сначала получать задания и передавать их обратно в Домен для создания расписания. Тот факт, что эти два понятия связаны друг с другом, означает, что связь помогает определить ваш домен и, следовательно, принадлежит к вашему доменному слою. Исключением может быть то, что как задание, так и график, подлежащий изменению, зависят от контекста от внешнего интерфейса (пользовательский ввод), но даже это не всегда является исключением.
• Не передавайте виртуальные машины в свой домен. Пусть ваш контроллер отфильтрует данные и определит, что нужно отправить в какую часть домена.

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

Могу ли я изменить/заменить это, не влияя на то, как работает мой бизнес/домен?

Если да, это не относится к вашему домену. Пример. Вы можете заменить весь ваш MVVM-интерфейс на плоский PHP или ASPX, и даже если это будет большой труд и огромная боль, вы можете сделать это, не затрагивая, как работает остальная часть бизнеса.