Советы новичку о приложениях N-уровня

Question

Хорошо, люди, вот еще один для вас:

Я начинаю в мире приложений n-уровня.Я немного почитал эту тему, и общий совет заключается в том, что целью n-уровневых приложений является абстрагирование функциональности между слоями.Таким образом, исходя из этого, в n-уровневом приложении обычная модель выглядит следующим образом:

Data Access -> Business Layer -> Presentation

Поскольку я являюсь разработчиком .NET, я подумал, что для улучшения интеграции с несколькими клиентамитипы (Silverlight, веб-приложение или даже клиент WinForms) Я должен использовать WCF (Windows Communication Foundation) в качестве службы данных на бизнес-уровне, чтобы клиенты могли общаться с ним независимо от его типа.Кроме того, я большой поклонник NHibernate как ORM.Итак, моя структура выглядит следующим образом:

Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms

Хорошо, так что это настройка.Я совершенно новичок в таком подходе, поэтому я подумал, что могу написать здесь с просьбой дать совет по этой настройке.Кроме того, я очень озадачен тем, как настроить это в решении VS. Мне нравится разделять слои в разных проектах, но как насчет абстракции объектов данных (таких как Customer, Order и т. Д.)?Я помещаю их в отдельную библиотеку?А как насчет WCF?Я знаю, что грех программиста - передавать классы данных по проводам клиенту.Как профессионал может этого добиться?

Спасибо, любой совет будет очень признателен.

Answer 1

Это в значительной степени в цель.N-Tier, однако, немного сложнее, чем N-Layer, и его можно противопоставить, спросив: «Действительно ли ваши уровни живут на отдельных физических серверах?»

В зависимости от сложности вашего бизнес-уровня, вы можетехочу абстрагировать его дальше между уровнем бизнеса и обслуживания.Обычно эти два связаны очень тесно и живут на одном физическом сервере.Сервисный уровень часто выступает в качестве фасада для вашего BLL.

Если вы находитесь на том же сервере, что и уровень Presentation, то приложения ASP.NET или WinForms могут захотеть обмениваться данными с BLL без прохождения через службы WCF..

Прочтите Microsoft Patterns & Practices - Руководство по архитектуре приложений .

Ваши доменные объекты должны находиться в собственной сборке, обычно в вашей доменной модели.В соответствии с Руководством по проектированию Microsoft Framework рекомендуется назначать сборки вашего проекта соответствующим образом:

[Company]. [ProductOrComponent]. [...]

Я получаючтобы любить этот формат пространства имен и обычно использовать:

[Company]. [Product]. [Layer]. [SubLayer]. [...]

Вот пример решенияиспользуя папки решений для организации каждого проекта:

В этом примере у меня есть слой BLL и Service.Уровень Service предоставляет фактическую реализацию в библиотеке WCF, в то время как презентация фактически содержит веб-приложение WCF для размещения служб.Всегда полезно отделять реализацию от интерфейса.

Папку / Client можно игнорировать, я просто использую ее в качестве примера консольного приложения для тестирования.Любые клиентские приложения, которые используют ваш сервис, вероятно, должны иметь свое собственное решение, или вы собираетесь управлять огромным решением.

Что касается вашего объекта данных, передаваемого по сети ... Я предполагаю, что вы имеете в видуклассы из вашего ORM.(Модель предметной области) Вы правы, это обычно считается плохой практикой.Решение использует объекты передачи данных.Вы можете видеть на картинке, у меня есть библиотека .Dto.Если вы в состоянии использовать такие инструменты, как AutoMapper, то, тем не менее, я за него, но добавление DTO к вашему решению влечет за собой дальнейшую сложность и обслуживание.Я считаю, что Дино Эспозито написал хорошую статью на эту тему.Постараюсь найти его для вас.

Надеюсь, это поможет.

---

[EDIT]

Должен заметить, я незнакомс возможностями nHibernate.Там могут быть лучшие решения для использования этого ORM.Я работал только с Entity Framework.

---

[РЕДАКТИРОВАТЬ 2]

Ознакомьтесь с Dino Esposito - Плюсы и минусы объектов передачи данных