多层体系结构-责任问题

Question

我正在开发一个实现多层模式的应用程序，其中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中的项目文件夹。内框是C#项目

在继续编写代码和在实际实现中花费更多时间之前，我只想得到一些关于我的项目的结构/架构的反馈。

我想问以下几个问题：

1. 上面的结构是“最佳实践”-conform吗？例如：接口位置，DTO
2. 是否可以有两个业务层，或者更确切地说，将业务层划分为客户机和服务器？服务器BLL旨在提供会话管理和安全等通用功能，而客户端BLL则提供服务访问。它也控制着主持人的观点。
3. 服务器端目前不知道域对象。在这里也使用它们会更好吗？这将导致将我的实体映射到域对象，然后映射到DTO。
4. 从WCF服务接收DTO是常见的，还是应该使用域对象(我知道这里已经讨论了很多，但据我了解，如果域对象不是那么复杂，并且可以在更改域对象和数据库时保存映射和编码efford )，这不是很难维护通信链吗?实体<->域对象<->DTO<->域对象
5. 你把验证放哪儿了？我想要对观点或陈述者进行基本的验证。格式，空/非空值，.)当主验证进入域对象时.？
6. 当在数据库中创建新记录时，假设是一个新用户，客户端也应该将一个新的DTO传递给服务器，还是创建一个接受简单数据类型(如string和int )的服务方法更好？

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

谢谢您的任何回答。

问候

Answer 1

您提议的结构与我们两年前在生产中部署的应用程序之一非常相似(比照)。它可以工作，但您必须仔细设计域模型，在不同的有界上下文中分离应用程序的各个方面。

以下是我自己的答案：

1. 不，这里没有“最佳实践”。经过5年的财务应用实践，笔者认为DDD仍是一个研究领域。但是，如果正确地将其应用于价值在于领域专家经验的项目，那么它就证明是非常好的。但是，您必须区分业务需求(与域相关的业务需求)和技术需求(这可以帮助绘制应用程序所需的组件和层)。
2. 业务层(如果需要识别一个)应该只处理业务规则。它是DDD应用程序中域模型的层。
3. 根据我的经验，如果您可以信任客户端机器，并且正确地设计域模型，则根本不需要任何Application。但是，如果您真的需要它(例如，因为客户端无法连接到db)，我将使它尽可能简单和无状态。这里一个有用的考虑因素是，大多数情况下，业务规则已经阻止并发访问可变实体。在这种情况下，不要尝试处理对这些实体的并发访问，只需构建一个互斥机制。
4. 对于进程间通信，只使用DTO。但是，您可以选择将整个域移动到Application (这将变得更加复杂和有状态)，并在客户机中使用更简单的MVC模式。从客户端开发人员的角度来看，这比较简单，但总体上比较昂贵(特别是很难扩展)。
5. 输入字段的简单类型验证可以在视图中完成(整数、日期时间等)，但是在将每个相关类型的值传递到域之前，您应该使用一个自定义值对象对其进行建模。例如，您不应该将字符串或十进制传递给域对象，而应该传递电子邮件或Money。此外，域中唯一负责业务不变的：它应该抛出表达性异常。时无法执行操作。
6. DTO更有表现力，因此更易于调试。

在你开始之前，我想你应该问自己一些问题：

1. 我是否需要一个领域专家，或者我可以通过阅读维基百科或一组写得很好的规范来了解业务？提示:不需要(至少)域专家==，不需要DDD。
2. 我能信任部署客户端的机器吗？如果不能，应该考虑将域移动到Application (并采用MVC模式客户端来处理WCF请求和DTO绑定)。

最后，如果您真的需要DDD，并且您是新手，您会发现Epic造型模式很有用(免责声明，我是Epic之一，在过去5年的DDD试用和错误中我都设计了它们)。

Answer 2

我一个接一个地回答

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

2)如果你说的是BLL，它应该只考虑业务逻辑，而不是任何技术细节，比如会话、安全性。

3)服务器端有域对象是很好的。它提高了可重用性。

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

5)根据范围对每个组件进行验证是很好的

6) DTO会更好

此外，您还可以使用WCF以外的服务堆栈，因为它建立在行业最佳实践的基础上。