Многоуровневая архитектура - Вопросы ответственности

Question

Я разрабатываю приложение, которое реализует многоуровневый шаблон, где MySQL используется для сохранения. Существует служба WCF, которая предоставляет доступ к данным и предоставляет DTO.

Кроме того, я планирую реализовать следующие модели: - DTOS - MVP (пока не уверен, что если пассивный вид или контроль контроллер) - код на интерфейсах, где применимые

В настоящее время я rawly имеют следующий проект Структура:

+-------------------------------+ 
|  MySQL DB Server   | 
+------+------------------------+ 
    ^
     | Uses Entity Framework 5.0 
     | 
     + 
+-------------------------------------------------------------------------------+ 
| Application Server               | 
|-------------------------------------------------------------------------------| 
|+------------------+ +----------------+ +--------------+ +--------------------+| 
|| Data Access Layer| | Contracts  | | Communication| | Business Layer  || 
||------------------| |----------------| |--------------| |--------------------|| 
|| - EF 5.0 Entities| | - WCF Contracts| | - WCF Service| | - Actual Service || 
||     | |    | | Hosts  | | - Session management| 
||     | |    | |    | | - Security and  || 
|+------------------+ +----------------+ +--------------+ +--------------------+| 
+-------------------------------------------------------------------------------+ 
     ^
     | Communicates via DTOs which are acutally wrappers for Entities 
     | eg. GetUserByID() or SaveUser(userDTO) 
     | 
     | 
+-------+-----------------------------------------------------------------------+ 
| Clients                  | 
|-------------------------------------------------------------------------------| 
|+-------------------+          +-------------------+| 
|| Business Layer |+----------------------------------->| GUI (Winforms) || 
||-------------------| BLL receives DTOs and creates  |-------------------|| 
|| -Provide WCF Servi| Domain Objects (eg. User) which are| -Implementation of|| 
|| ce Access  | Processed by presenters and passed | View Interfaces || 
|| -Service Reference| to views where they are bound to |     || 
|| -Implementation of| controls.       |     || 
|| Presenter Interf.|          |     || 
|+-------------------+          +-------------------+| 
+-------------------------------------------------------------------------------+ 



+------------------------------------------------------------------------+ 
| General                | 
|------------------------------------------------------------------------| 
|+---------------------+ +--------------------+ +-----------------------+| 
|| DTOs    | | Interfaces   | | Library    || 
||---------------------| |--------------------| |-----------------------|| 
|| -DTO Definitions | | -View Interfaces | | -General Helper Classe|| 
||      | | -Presenter Interf. | | s eg. Cryptography || 
||      | | -Domain Model IF. | |      || 
|+---------------------+ +--------------------+ +-----------------------+| 
+------------------------------------------------------------------------+ 

Наружные коробки - это папки проектов в Visual Studio. Внутренние коробки: C# Проекты

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

Я оборачивать вокруг моей головы следующие вопросы:

1. ли выше структура «лучшей практики» -conform? например. расположение интерфейсов, DTO
2. Можно ли иметь два бизнес-уровня или, скорее, разделить бизнес-уровень на клиент и сервер? Сервер BLL предназначен для обеспечения общих функций, таких как управление сеансом и безопасность, в то время как клиент BLL предоставляет доступ к услугам. Он также управляет просмотрами его докладчиками.
3. В настоящее время серверная часть не знает о доменных объектах. Было бы лучше, если бы они использовали здесь ? Это приведет отображение моих объектов к объектам домена, а затем DTOS
4. Есть ли общие для получения DTOs от WCF службы или я должен использовать домен объекты (я знаю, что уже обсуждалось здесь много, но от чего I понимаете, это применимо, если объекты домена не являются , которые сложны и могут сохранить отображение и кодирование при изменении моих доменных объектов и базы данных) Не приведет ли это к очень сложной цепочке связи, например: Объекты < -> Объект домена < -> DTO < -> Объект домена
5. Где вы размещаете проверку ? Я думал поставить базовую проверку в просмотры или презентаторы (например, форматирование, null/not null values, ...), а основная проверка идет на объекты домена ...?
6. При создании новой записи в базе данных, скажем, новый пользователь, , должен ли клиент также передать новый DTO на сервер, или лучше создать метод службы, который допускает простые типы данных, такие как строка и int ?

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

Заранее благодарим за любой ответ.

С уважением

Answer 1

Структура, которую вы предлагаете, очень похожа (mutatis mutandis) на одно из наших приложений, которое было развернуто в производстве 2 года назад. Он работает, но вы должны тщательно спроектировать модель домена, разделяя в разных ограниченных контекста различные аспекты приложения.

Так что это мои собственные ответы:

1. Нет, нет «лучшей практики», чтобы соответствовать здесь. После 5 лет практики DDD в финансовых приложениях мое собственное мнение заключается в том, что DDD по-прежнему является полем исследований. Тем не менее, это очень хорошо, если правильно применять проекты, стоимость которых находится в опыте эксперта . Однако вам необходимо различать бизнес-потребности (относящиеся к домену) и технологические требования (которые могут помочь в рисовании компонентов и уровней, которые необходимы вашему приложению)
2. Бизнес-уровень (если вам нужно его идентифицировать) должен обрабатывать бизнес-правила только. Это слой моделей домена, в приложении DDD.
3. По моему опыту, если вы можете доверять машине-клиенту и правильно спроектировать модель домена, вам не нужен ни один сервер приложений. Однако, если вам это действительно нужно (например, потому что клиенты не могут подключиться к db), я бы сделал это как можно проще и без гражданства. Полезным соображением здесь является то, что в большинстве случаев бизнес-правила уже предотвращают одновременный доступ к изменяемым объектам. Не пытайтесь обрабатывать одновременный доступ к таким объектам в этом случае, просто создайте механизм взаимного исключения.
4. Для взаимодействия между процессами используйте только DTO. Однако вы можете выбрать перемещение всего домена на сервер приложений (который станет намного более сложным и состоятельным) и использовать более простой шаблон MVC в клиенте. Это проще с точки зрения разработчика клиента, но более дорогостоящего в целом (в частности, его сложно масштабировать).
5. Простой тип проверки полей ввода может быть выполнен в представлении (целые числа, даты и т. Д.), Но вы должны моделировать каждый соответствующий тип значения с помощью специального объекта значения перед его передачей в домен. Например, вы никогда не должны передавать строки или десятичные значения для объектов домена, но Email или Деньги.Кроме того, домен в единственной ответственной для бизнес-инварианта: it should throw expressive exceptions, когда операция не может быть выполнена.
6. DTO более выразительны, поэтому их легче отлаживать.

Перед тем, как начать, я думаю, вы должны задать себе несколько вопросов:

1. ли нужен специалист домена или я могу узнать достаточно бизнеса, читая Википедию или набор хорошо написанных спецификаций? Подсказка: нет необходимости (по крайней мере) эксперту домена == нет необходимости в DDD.
2. Могу ли я доверять машинам, где будет развернут клиент? Если вы этого не сделаете, вам следует переместить домен в Сервер приложений (и принять клиентскую часть шаблона MVC для обработки запросов WCF и привязок DTO).

Наконец, если вам действительно нужно DDD, и вы новичок в этом, вы могли бы найти Epic's modeling patterns полезные (отказ от ответственности, я один из разработчиков компании Epic и я проектировал все из них в течение последних 5 лет DDD-проб и ошибок).

Answer 2

Отвечу один на один

1) Зависит от сложности приложения. Если ваш работают на комплексной области его хорошо следовать домен Driven Design

2) Если вы говорите, BLL, он должен принимать только заботу о бизнес-логике, а не какие-либо технические данные, как сессия, безопасность ..

3) Хорошо иметь объекты домена на стороне сервера. Он способствует повторному использованию

4) Вы не должны выставлять объекты домена снаружи. DTO - лучший вариант. Вы можете использовать Automapper для все отображения работы, связанных с

5) Его хорошо иметь валидации в каждом компоненте в зависимости от объема

6) DTOS будет лучше

Кроме того, вы можете устранить стек, чем WCF, как он построен на лучших отраслевых практиках.