Хорошие причины не размещать ViewModels в отдельной сборке?

Question

Я разрабатываю проект с использованием шаблона MVVM в WPF.

Одним из ключевых преимуществ MVVM является поддержание четкого разделения между бизнес-логикой и презентацией.

В качестве теста, чтобы увидеть, насколько хорошо отделилось все, что было на самом деле, в выходные я пропустил перемещение всех ViewModels, моделей и бизнес-логики в отдельную .dll. Файл .exe оставлен как тонкий слой презентации.

Это сработало, легко, сперва.

Я уже видел преимущества сохранения представлений (xaml, presentation) в .exe и основной логике в своей собственной DLL. Например, в моем сознании больше нет anydilemma о том, есть ли проблема с кодом в Xaml: мне это удобно, если это становится необходимым, так как я знаю, что это особенность презентации.

До сих пор это разделение exe/dll работало так хорошо, что мой вопрос: кто-нибудь испытал какой-либо недостаток для этого подхода?

Связанные вопрос: Implementing MVVM in WPF without using System.Windows.Input.ICommand

Answer 1

2 недели с моей моделью & Просмотреть модели в dll, моем xaml в exe и никаких проблем вообще.

Answer 2

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

Answer 3

Мы используем такое разделение во всех наших продуктах, потому что это помогает нам увидеть, не нарушен ли какой-либо код против разделения пользовательского интерфейса - бизнес-логики.

В большинстве случаев мы делаем это таким же образом, как вы предложили:

• Sample.Presentation.exe (содержит все вещи, WPF, тонкая сборка)

• Sample.Applications.dll (отвечает на рабочий процесс приложения, здесь все ViewModels)

• Sample.Domain.dll (Вот бизнес-правила)

Мы еще не сталкивались с какими-либо проблемами, и я не ожидаю увидеть какие-либо проблемы в будущем.

Answer 4

Актуальный вопрос: для чего собираются?

Это способ разделить логику, которая делает ее недоступной для другого кода, если вы не добавите ссылку, так что на самом деле это способ сокрытия частей кода из других частей.

Учитывая эту цель и то, как вы ее используете, я бы сказал, что вы делаете это правильно.

Сказав, что мне гораздо легче проверить, что в представлениях нет кода, содержащегося в обзорах кода, и сохраняйте представления в одной и той же сборке. Меньше проектов = более быстрое время компиляции и загрузки.