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

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

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

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

Это сработало, легко, сначала попробуйте.

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

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

Ответ 1

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

Ответ 2

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

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

Sample.Presentation.exe(содержит все материалы WPF, тонкую сборку)
Sample.Applications.dll(отвечает за рабочий процесс приложения, вот все ViewModels)
Sample.Domain.dll(Вот бизнес-правила)

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

Ответ 3

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

Ответ 4

Фактический вопрос: какие сборки для?

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

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

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