Лучшие практики для создания сервисов RIA DomainContext

Question

Если вы ссылаетесь на любые образцы MVVM разработанного Silverlight, вы обнаружите, что каждая ViewModel имеет свой собственный DomainContext.Однако я не вижу необходимости иметь специфичный для ViewModel DomainContext.

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

Кто-нибудь может сказать мне, что говорят лучшие практики для DomainContext?

Answer 1

Мои два учебника по MVVM, которые ...

Создание корпоративных приложений с помощью Windows® Presentation Foundation и модели представления модели представления Раффаэле Гарофало

Pro WPF и Silverlight MVVM Эффективная разработка приложений с Model-View-ViewModel Гэри Маклин Холл

... не обращаются напрямую к DomainContext.Однако оба автора согласны с тем, что в отношении уровня доступа к данным рекомендуется использовать шаблон проектирования «Единица работы».Если вы планируете использовать один или несколько DomainContext (s) в приложении SL в качестве части вашего уровня доступа к данным, вам будет рекомендовано (в любом случае, этими органами) рассмотреть возможность их включения в шаблон «Единица работы».Пусть ваша ViewModel справится с этими абстракциями.

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

В «Единица работы» можно ознакомиться по адресу http://msdn.microsoft.com/en-us/magazine/dd882510.aspx

Answer 2

Есть много способов сделать это, поэтому лучшее, что я могу сделать, это поделиться тем, что я делаю.

1) Создайте каждый контекст домена на основе функции. Например, у меня будет контекст для всех функций пользователя, один для всех функций клиента, один для функций заказа и т. Д. Это позволяет проводить чистую сегментацию BusinessLayer.

2) Создание пользовательских классов в веб-проекте, которые будут возвращаться вместо абстрактных представлений, созданных мастером. У меня лично есть проблема с возвращением имени моего БД, указанного в IQueryAble, в проект Silverlight, поскольку проект Silverlight можно рассматривать как слой пользовательского интерфейса. Это косвенно вызывает зависимость от DataLayer, чего мы не хотим. Да, это создает больше работы с добавлением дополнительных классов, но помогает обеспечить абстракцию для правильной трехслойной архитектуры.

3) Создайте пользовательские классы на уровне пользовательского интерфейса, которые переваривают возвращаемые данные из отображенных методов (из DataContext). Это помогает применять абстракцию.

Помните, конечная цель - сделать ваш код как можно более слабосвязанным. Это всегда требует дополнительного (и иногда избыточного) кодирования с вашей стороны, но конечный результат стоит усилий.

Вы также можете рассмотреть возможность создания библиотеки классов RIA; что позволяет вам абстрагироваться дальше. Это не самая простая реализация, но это шаг в правильном направлении при попытке облегчить взаимодействие между Silverlight и веб-проектами.