Должны ли мы использовать сервис WCF в качестве фасада нашего уровня сервиса в приложении nTier - PullRequest
Новая
       45

Должны ли мы использовать сервис WCF в качестве фасада нашего уровня сервиса в приложении nTier

2 голосов
/ 06 марта 2012

Поэтому мы решили перестроить приложение в нашем бизнесе, поскольку оно находится в Sharepoint без видимой причины, кроме как использовать функцию индексации документов.

Мы решили создать наше новое приложение в ASP.NET MVC3 с использованием C #. Мы пытаемся определиться с общей архитектурой.

Я думал что-то вроде следующего:

  • Core - доменные объекты (poco's)
  • Данные - Entity Framework (сначала код) или nHibernate, представленные в качестве репозиториев
  • Сервис - этот уровень будет инкапсулировать любую бизнес-логику и действовать как фасад. Это может быть разбито на дополнительные модули.
  • UI (MVC) - Контроллеры и представления.

Все это будет связано вместе с помощью DI-контейнера, такого как Autofac.

Мы также хотим иметь возможность писать модульные тесты, поэтому мы должны иметь возможность макетировать наш сервисный уровень и хранилища данных для тестирования наших контроллеров и т. Д.

Итак - это звучит как хороший общий архитектурный шаблон для довольно стандартного бизнес-приложения?

Идея состоит в том, что данные, сервис, пользовательский интерфейс могут ссылаться на Core, но пользовательский интерфейс будет действительно общаться только с компонентами уровня сервиса и не знать о деталях реализации данных и т. Д.

Мой следующий вопрос заключается в том, что в какой-то момент мы захотим показать некоторые функции вне нашего приложения, например, WCF Services / ASP.NET Web API.

Что, на ваш взгляд, будет лучшим вариантом. Построить сервисный уровень в WCF и вызвать его из наших контроллеров в MVC? Если это так, будет ли это тестируемым или нам нужно написать оболочку для веб-службы? Может ли это занять много времени?

OR

Продолжить написание сервисного уровня (т. Е. Service1.CreateObject (object obj);) в классах C # и создать веб-сервис как отдельный объект, предоставляющий только те функциональные возможности, которые нам нужны, которые вызывают наш сервисный уровень?

Любые мысли были бы очень полезны, так как я не знаю, какой будет лучший маршрут.

Ответы [ 2 ]

2 голосов
/ 06 марта 2012

Если мы будем использовать службу WCF в качестве нашего фасада уровня службы в приложении nTier

Зависит от того, будет ли какое-либо другое приложение, кроме приложения MVC, взаимодействовать со службой.

  • MVC3 - единственное приложение : оно вам не нужно
  • Другие приложения тоже : Конечно.Сделайте это.

Что, на ваш взгляд, будет лучшим вариантом.Построить сервисный уровень в WCF и вызвать его из наших контроллеров в MVC?Если это так, будет ли это тестируемым или нам нужно написать оболочку для веб-службы?Может ли это занять много времени

Не используйте конкретные классы обслуживания.Используйте сервисные интерфейсы.Проблема решена.

Мой следующий вопрос заключается в том, что в какой-то момент мы захотим показать некоторые функции вне нашего приложения, например, WCF Services / ASP.NET Web API

Я надеюсь, что вы имеете в виду один и тот же сервис WCF.

Продолжайте писать сервисный уровень (т. Е. Service1.CreateObject(object obj);) в классах C # и создайте веб-сервис как отдельный объект, предоставляющий только те функции, которые нам нужны.что вызывает наш уровень обслуживания?

эхх.Какой метод Service1.CreateObject(object obj)?Это выглядит просто неправильно.

1 голос
/ 06 марта 2012

Использование службы WCF - правильный подход. (Поскольку вам нужно разместить его, так как web-api и web-api over http).

В вашем приложении MVC вы можете использовать сервис по URL конечной точки.

Фактор времени зависит от соединения между вашими серверами (приложением WebServer for MVC и сервером для размещения WCFservices). В действительности это не должно быть узким местом.

Тем не менее, вы можете выполнить модульное тестирование кода MVC (так как вызов уровня обслуживания может быть смоделирован. (Используя Moq / NMock? RhinoMock ...))

...