Architecture 多层体系结构-责任问题

我正在开发一个实现多层模式的应用程序，其中 MySQL用于持久性。有一个提供访问权限的WCF服务 提供数据和DTO

此外，我计划实现以下模式： -DTOs -MVP（不确定是被动查看还是监控控制器） -适用时针对接口的代码

目前，我的项目结构如下：

+-------------------------------+
|     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#项目

在我继续编码并在实际实现中花费更多时间之前，我只需要 我想获得一些关于我的项目结构/架构的反馈

我在思考以下问题：

上述结构是否符合“最佳实践”？ 例如，接口、DTO的位置

可以有两个业务层吗，或者更确切地说，可以拆分业务层吗 进入客户端和服务器？ 服务器BLL旨在提供会话管理等一般功能 客户端BLL提供服务访问时的安全性。它控制着 它的演示者的观点也是如此

服务器端目前不知道域对象。会吗 在这里使用它们更好吗？这将导致映射我的 实体到域对象，然后到DTO

从WCF服务接收DTO是常见的还是应该使用域 对象（我知道这里已经讨论了很多，但是从什么角度 我理解，如果域对象不是 这很复杂，并且在更改时可以节省映射和编码工作量 我的域对象和数据库） 这会不会导致一个非常难以维护的通信链，如： EntitiesDomainObjectdToDomain对象

你把验证放在哪里？我想把基本的验证放在 视图或演示者（例如格式化、空值/非空值…） 主验证转到域对象

在数据库中创建新记录时，比如说新用户， 客户机是否应该向服务器传递一个新的DTO，还是创建一个新的DTO更好 接受简单数据类型（如string和int）的服务方法

很抱歉这么长的帖子，但我认为最好结合我的 将问题集中到一个帖子中，并在其中提供项目结构

提前感谢您的回答

---

问候

我会一一回答

1） 这取决于应用程序的复杂性。如果您从事的是复杂领域的工作，那么遵循领域驱动设计是很好的

2） 如果您说BLL，它应该只考虑业务逻辑，而不考虑任何技术细节，如会话、安全性

3） 在服务器端有域对象是很好的。它促进了可重用性

4） 不应在外部公开域对象。DTO是更好的选择。您可以使用Automapper进行所有与映射相关的工作

5） 根据范围在每个组件中进行验证是很好的

6） DTO会更好

---

此外，您可以使用比WCF更高的服务堆栈，因为它是基于行业最佳实践构建的。

我将逐一回答

1） 这取决于应用程序的复杂性。如果您从事的是复杂领域的工作，那么遵循领域驱动设计是很好的

2） 如果您说BLL，它应该只考虑业务逻辑，而不考虑任何技术细节，如会话、安全性

3） 在服务器端有域对象是很好的。它促进了可重用性

4） 不应在外部公开域对象。DTO是更好的选择。您可以使用Automapper进行所有与映射相关的工作

5） 根据范围在每个组件中进行验证是很好的

6） DTO会更好

---

此外，您还可以为stack而不是WCF提供服务，因为它是基于行业最佳实践构建的。

您建议的结构与我们两年前在生产中部署的一个应用程序非常相似（经过必要的修改）。它可以工作，但是您必须仔细设计域模型，在不同的有界上下文中分离应用程序的各个方面

以下是我自己的答案：

不，这里没有符合的“最佳实践”。经过5年的DDD金融应用实践，我个人的观点是DDD仍然是一个研究领域。然而，如果能正确地应用于价值在于领域专家经验的项目，它将被证明是非常好的。但是，您必须区分业务需求（与领域相关）和技术需求（有助于绘制应用程序所需的组件和层）

业务层（如果您需要确定一个）应该只处理业务规则。它是DDD应用程序中的域模型层

根据我的经验，如果您可以信任客户机，并且正确地设计了域模型，那么您根本不需要任何应用程序服务器。但是，如果您真的需要它（例如，因为客户端无法连接到db），我会使它尽可能简单和无状态。这里一个有用的考虑是，大多数时候，业务规则已经阻止了对可变实体的并发访问。在这种情况下，不要试图处理对此类实体的并发访问，只需构建互斥机制即可

对于进程间通信，仅使用DTO。但是，您可以选择将整个域移动到应用程序服务器中（这将变得更加复杂和有状态），并在客户机中使用更简单的MVC模式。从客户开发人员的角度来看，这更简单，但总体上更昂贵（特别是，它可能很难扩展）

输入字段的简单类型验证可以在视图中完成（整数、日期时间等），但是在将每个相关类型的值传递到域之前，应该使用自定义值对象对其进行建模。例如，永远不要将字符串或小数传递给