Есть ли причина не хранить ViewModels в отдельной сборке, запрещенной по xaml?

Question

Просто интересно, стреляю ли я себе в ногу, если я помещаю все свои модели ViewModel в отдельную сборку из xaml моего приложения silverlight?Я теряю какую-либо смешиваемость?

Мне кажется более естественным иметь ViewModel, которые (или должны быть) полностью независимы от пользовательского интерфейса, в отдельной сборке из Xaml / views.

Потеряю ли я что-нибудь в области смешиваемости?

Я думаю, что это в значительной степени заставляет упростить юнит-тестирование, или я что-то упускаю?

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

Answer 1

В этом нет необходимости, но это может быть полезно, если вы стремитесь к архитектурной чистоте. Хотя повторное использование библиотеки VM не является распространенным явлением (как сказал LBugnion), довольно часто переоснащают ваш пользовательский интерфейс (или создают новый), и в этом случае может быть очень удобно иметь сборку только для пользовательского интерфейса.
Это также делает вещи простыми, если вы делаете то, о чем я слышал, о чем говорили, но никогда не видели в реальной жизни: иметь независимого дизайнера UX, работающего над пользовательским интерфейсом, в то время как остальные разработчики делают настоящий код за кулисами.

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

Answer 2

Пока библиотеки включены в решение, вы можете ссылаться на ViewModels и не терять Blendability ".

Обычно (так как мы используем PRISM) мы собираем всю информацию, относящуюся к бизнес-доменам, в один модуль, поэтому он будет включать в себя Views, ViewMOdels, Controllers и т. Д., Но с отдельной библиотекой ViewModel (или библиотеками) все в порядке, и вы используете MVVM Свет.

Answer 3

Мы часто делаем это для больших приложений. Для маленьких это обычно не действительно нужно. Такое разделение сборок не имеет реального технического преимущества (вы редко используете библиотеку ВМ), поэтому речь идет об организации работы и структуре. Что касается Blendability, вы ничего не теряете. Кроме того, если вы работаете со службами, вам нужно иметь определение интерфейса в библиотеке VM (или в третьем проекте).

Обратите внимание, что иногда вы получаете запутанные сообщения об ошибках сборки. Если библиотека VM не компилируется, вы можете увидеть ошибки о несуществующих объектах в XAML, которые просто вызваны тем, что библиотека еще не построена. Не запутайся.

Приветствие Laurent