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

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

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

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

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

Ответы

Ответ 1

Это в значительной степени на цель. Однако N-Tier немного сложнее, чем N-Layer, и его можно противопоставить, спросив: "Являются ли ваши слои на разных физических серверах?"

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

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

Прочитайте Шаблоны и методы Microsoft - Руководство по архитектуре приложений.

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

[О компании]. [ProductOrComponent]. [...]

Мне нравится этот формат межстрочного интервала и обычно используется:

[О компании]. [Product]. [Layer]. [Подуровень]. [...]

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

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

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

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

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

[EDIT]

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

[ИЗМЕНИТЬ 2]

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