Путаница в проектировании архитектуры сервисного уровня

Я использую MVC 3. Я пытаюсь разобраться в уровне служб и службе. В настоящее время я работаю над примером приложения, которое поставляется с исходным кодом DoFactory. Этот вопрос основан на примере приложения, но в целом.

Существует сервисный уровень (WCF), который предоставляет набор сервисных методов. Сервисный уровень реализует единую точку входа (шаблон фасада), через которую должна осуществляться вся связь с нижележащими уровнями. Фасад — это точка входа на бизнес-уровень, предоставляющая очень простой API-интерфейс.

Допустим, я пытаюсь получить список клиентов, затем в контроллере MVC он вызовет метод GetCustomers репозитория, а затем вызовет метод GetCustomers сервисных слоев.

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

Пожалуйста, может кто-нибудь помочь прояснить это?


person Brendan Vogt    schedule 31.12.2010    source источник


Ответы (1)


Ваша архитектура правильная.

Я всегда думал, что репозиторий всегда был последним методом, вызываемым для получения данных?

Да, в вашем случае данные поступают из службы WCF, но это может быть что угодно: база данных SQL, файл XML,...

person Darin Dimitrov    schedule 02.01.2011
comment
Спасибо. Значит, вам не нужна служба, которая вызывает репозиторий, который, в свою очередь, получает данные из службы WCF? Где будет применяться логика в этом случае, на сервисном уровне WCF? - person Brendan Vogt; 02.01.2011
comment
@ Брендан, нет, в этом случае вам не нужна дополнительная услуга. Бизнес-логика будет применяться на уровне WCF. - person Darin Dimitrov; 02.01.2011
comment
Спасибо! Я просто был сбит с толку сервисом и сервисным уровнем. Вы меня прояснили :) - person Brendan Vogt; 02.01.2011