最佳实践-多层体系结构和DTO

在不同的层之间包含一些软件包并不罕见，但是通常仅针对诸如日志记录之类的跨领域问题才这样做。您的模型不应由不同的层共享，否则对模型的更改将需要在所有这些层中进行更改。通常，您的模型是一个较低的层，靠近数据层（取决于方法，位于数据层的上方，下方或相互缠绕）。

顾名思义，数据传输对象是用于传输数据的简单类。因此，它们通常用于层之间的通信，特别是当您具有通过消息而不是对象进行通信的SOA体系结构时。DTO应该是不变的，因为它们仅存在于传递信息而不是改变信息的目的。

域对象是一回事，DTO是另一回事，而表示层所需的对象又是另一回事。但是，在小型项目中，实施所有这些不同的集合并在它们之间进行转换可能不值得。那只取决于您的要求。

您正在设计Web应用程序，但可能会帮助您设计自己：“我可以通过桌面应用程序切换Web应用程序吗？我的服务层真的不了解我的表示逻辑吗？”。用这些术语思考将指导您迈向更好的体系结构。

关于您的问题：

假设持久层将使用类myproject.persistence.domain.UserEntity（基于JPA的实体）来向数据库存储数据或从数据库加载数据。为了在视图中显示数据，我将提供另一个类myproject.service.domain.User。我在哪里转换？用户服务将负责在两个类别之间进行转换吗？这真的有助于改善耦合吗？

服务层知道其类（DTO）以及其下的层（比如说持久性）。因此，是的，该服务负责在持久性和自身之间进行转换。

User类的外观如何？它应该只包含不可变的吸气剂吗？视图编辑现有用户（创建新用户，使用现有User对象的getter等）是否繁琐？

DTO背后的想法是，仅将它们用于传输，因此不需要诸如创建新用户之类的操作。为此，您需要不同的对象。

我应该使用相同的DTO类（用户）向服务发送请求以修改现有用户/创建新用户，还是应该实现其他类？

服务方法可能表示操作，DTO是仅包含数据的参数。另一种选择是使用表示操作并还包含DTO的命令。这在SOA体系结构中很流行，在SOA体系结构中，您的服务可能只是一个命令处理器，例如，具有一个Execute将ICommand接口作为参数的单个操作（而不是每个命令一个操作）。

通过使用myproject.service.domain中的所有DTO，表示层是否会非常依赖于服务层？

是的，服务层上的层将取决于它。那是主意。好的方面是，只有该层依赖于该层，而没有上层或下层依赖，因此更改只会影响该层（与从每一层使用域类的情况不同）。

如何处理我自己的异常？我当前的方法会抛出大多数“严重”异常，直到它们由表示层处理（通常将它们记录下来，并告知用户发生了问题）。一方面，我有一个问题，就是我再次拥有一个共享软件包。另一方面，我仍然不确定这是否可以视为“最佳实践”。有任何想法吗？

每个层可以有自己的异常。它们从一层流到另一层，封装到另一种异常中。有时，它们将由一层处理（例如，进行日志记录），然后可能抛出上层必须处理的另一种异常。在其他时候，可能会处理它们并可能解决问题。例如，考虑连接数据库的问题。它将引发异常。您可以处理它并决定一秒钟后重试，然后可能成功了，因此异常不会向上传播。如果重试也失败，则异常将被重新抛出，并且可能一直流到表示层，在此您可以优雅地通知用户并要求他重试该层。