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

Question

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

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

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

Это сработало без проблем, первая попытка .

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

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

Смежный вопрос: Реализация MVVM в WPF без использования System.Windows.Input.ICommand

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

Фактический вопрос ... для чего нужны сборки?

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

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

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