WCF и N-уровневая архитектура

Question

Я работаю над приложением, которое было разработано с использованием архитектуры приложений n-tyre. Приложение было разработано на платформе .NET с использованием C #, VB.NEt, Framework 3.5, Dataset, WCF, панели обновления asp.net, JavaScript, Josn, сторонние инструменты. мой текущий предложенный макет такой

уровень представления -> Бизнес-логика -> WCF -> DAL-> Доступ к данным

Дело в том: Является ли приведенная выше схема правильным способом построения систем SOA?

Как всегда, ваш совет очень ценится

Answer 1

Это зависит от вашего определения, см. Комментарии Фаулера .

Как правило, чтобы получить максимальную выгоду от чего-то SOA, ваши сервисы должны быть рассчитаны на повторное использование несколькими потребителями. Это означает, что ваша бизнес-логика должна быть «под» вашим уровнем WCF. Тогда вы можете иметь, например, клиента Silverlight, клиента WPF и т. Д., Использующих те же сервисы и бизнес-логику.

Измените свой сценарий на:

Несколько уровней представления -> WCF -> Бизнес-логика -> DAL-> Доступ к данным

Answer 2

Похоже, это МОЖЕТ быть правильным, хотя я бы также поместил WCF между вашими слоями Pres и Biz. Кроме того, не бойтесь иметь нелинейный путь для вашей архитектуры SOA (т. Е. Иметь побочные сервисы, такие как «EmailService» и «WeatherDataService», которые исходят со стороны вашего пути N-уровня. Очевидно, что WeatherDataService будет исходить из сторона вашего DAL, но EmailService может исходить со стороны вашего уровня Biz.

Несколько замечательных ссылок для вас:

• Выполнение N-ярусов с WCF
• WCF и наборы данных с N-ярусами
• N-ярус с WCF, MVC и LINQ

Answer 3

Ваши услуги должны быть бизнес-операциями, а не операциями с данными. Лучшая версия вашего дизайна будет: Уровень представления -> WCF -> Бизнес-логика -> Доступ к данным.

N-ярус / расслоение в наше время является довольно устаревшей концепцией. Это всегда ломалось. Instaed, думайте о своем программном обеспечении как о количестве взаимодействующих сервисов.