WPF WCF Prism и MVVM - правильный способ раскрытия сущностей

Question

Мы собираемся в ближайшее время разработать крупное корпоративное настольное приложение, и я потратил некоторое время на изучение подхода WPF + PRISM + MVVM. Я хорошо разбираюсь в большинстве концепций и мне нравится модульность, которую он обеспечивает..

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

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

Например,

Module1 Содержит службу WCF + службу конкретных приложений (ISearchService) + объекты, созданные службой WCF (модель)

Module1.Infastructure - Содержит следующий интерфейс дляслужба приложений

public interface ISearchService
{
      ObservableCollection<Person> Search(string search);
}

это будет зарегистрировано в UnityContainer, чтобы любой другой модуль мог получить конкретную реализацию, замешанную модулем.

Моя проблема в том, что сущности (Person) определены в самом модуле (в службе WCF), поэтому введение службы и ожидание возможности использования ее другими модулями означает, что им нужно ссылаться на сам модуль, а не только на его структуру, если только я не извлекаю службыв другую сборку.

Должен ли я таким образом выставлять свои энты, которые автоматически генерируются из моей модели EF?

У кого-нибудь есть лучшее решение?

Answer 1

Вот как это сделал.

В настоящее время я пользуюсь услугами Silverlight + PRISM + MVVM + WCF (RIA).

С текущей архитектурой проекта

• Application.Domain: Содержит все первые сущности кода EF, включая метаданные и проверку бизнеса. Не включает генерацию базы данных.

• Application.RIAServices: Этот проект содержит автоматически созданные классы из веб-проекта служб RIA WCF. Я могу сослаться на этот проект как в WPF, так и в Silverlight.

• Application.RIAServices.Web: веб-проект, содержащий DomainServices и код создания базы данных с использованием DbContext. это ссылочный проект WCF RIA для Application.RIAServices

• Application.Infrastructure: это то, где это начинается. Потому что, как и у вас, у меня есть Служба поддержки персонала / клиентов, использующая интерфейс ICustomerService. Поскольку я хочу использовать этот сервис, например, для всего приложения, а не только для ModuleA, я помещаю этот интерфейс в инфраструктуру. Все проекты содержат ссылку на этот проект.

• Application.Modules.ModuleA -> Application.Modules.ModuleD: Общие модули, обеспечивающие функциональность. Все мои модули (которые используют службы WCF RIA) имеют ссылку на проекты Application.Infrastructure и Application.RIAServices.

• Application.Shell: запуск проекта. наличие загрузчика и регистрация всех соответствующих модулей.

Чтение вопроса Рэйчелс заставило меня задуматься о некоторых вещах, и я просто хотел оставить свою структуру о том, как я это сделал. Вы можете иметь представление об этом. Я пока не хочу идти в DTO, потому что такие вещи, как валидация, настолько хорошо интегрированы в сервисы RIA WCF, что автоматически отображают в текстовом поле, когда что-то не так, и отображают сообщение об ошибке. Будем рады услышать ваше мнение и результаты вопроса / проблемы

Edit:

Application.Domain также имеет отдельную структуру.

У меня есть мои модели. Только контейнер чистых свойств, которые должны быть сопоставлены с базой данных. Тогда у меня есть папка с метаданными. Теперь, чтобы это работало, мне нужно иметь то же пространство имен, что и у моей сущности, и я делаю эту сущность частичной. Я создаю файл Entity.metadata.cs и там я создаю internal sealed class EntityMetaData, копируя свойства и добавляя к ним атрибуты. Используя атрибут MetadataType над классом Entity, он добавляет все эти атрибуты в генератор кода EF / WCF RIA.

Одним из этих атрибутов является CustomValidation, он использует статический класс и параметр метода и проверяет сущность на сервере. Или, если вы создаете файл с расширением .shared.cs, он создается в проекте Application.RIAServices.

Возможность

Чтобы попытаться ответить на ваш вопрос, у вас может быть только 1 вариант, и это то, что вы предложили сначала. Вы можете создать проект Customer.Infrastructure.

этот проект содержит интерфейс для ICustomerService, Entity / DTO / POCO, что вы когда-либо захотите, и, возможно, даже реализацию этого ICustomerService или службы WCF. Это позволяет всем вашим модулям ссылаться на этот проект и, следовательно, не создавать зависимости между модулями.

Answer 2

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