使用DTO是解决这个问题的最好方法吗？

Question

我正在开发一个客户端/服务器系统：

有一个数据库、一个应用程序服务器和一个用户界面（客户端）应用程序。应用程序服务器处理来自客户端应用程序的连接，当客户端应用程序请求用户列表或通过 ID 请求特定对象时，客户端应用程序又与数据库进行通信。

目前我有一组数据对象，如“用户”、“区域”等，它们映射到数据库中的表。这些数据对象在共享库中定义，该共享库在编译时链接到客户端和应用程序服务器。它们继承一个允许它们序列化的类，以便它们可以在客户端和服务器之间传递，并且它们采用“数据提供者”作为依赖项注入，以允许提交发送到应用程序服务器或发送到数据库，具体取决于是否它们在客户端或服务器端使用。

当客户端应用程序的用户想要编辑用户时，它会从应用程序服务器请求该对象，使用它用当前值填充用户界面，允许用户编辑这些值，然后“提交”回该对象到应用程序服务器，应用程序服务器又将其提交到数据库。

这对于这个非常简单的场景来说很好，但是随着它变得更加复杂，用户界面将需要可能由几个底层数据库对象组成的对象，所以我想我需要在某种程度上从数据库模型中抽象出来。

在这种情况下，我不应该将我认为所谓的“DAL”对象传递到用户界面（通过序列化），所以我想我需要一些 DTO（数据传输对象）。

我还发现在执行业务逻辑的应用程序服务中，我目前正在通过切换从客户端提交的对象类型，执行任何必要的操作，然后提交到数据库来处理这一切。我想也许在这里我需要业务对象，每个对象都知道如何验证和操作。

所以我可能最终会得到：

Shared:
 * UserDTO (data transfer object)

Application Server:
 * UserDAL (data access object)
 * UserBO (business object, contains UserDAL)
 * UserDTO (data transfer object as defined in shared lib)

Client:
 * UserDTO (data transfer object as defined in shared lib)

因此，客户端请求用户 DTO，根据需要显示或更新，调用“保存”方法，它被序列化并发送到应用程序服务器，应用程序服务器对其进行反序列化，创建业务对象可以对其执行任何操作（例如验证、保存到数据库等）。

这意味着删除从 DAL 对象到 DTO 对象的所有序列化逻辑，并删除我的大型业务逻辑类，并且将阻止表示层（客户端）了解有关数据库结构的任何信息。

这听起来正确吗？

其他人确实建议将业务对象放在共享库中，而不是使用数据传输对象。但问题是我在两个地方都有业务逻辑，如果能够在一处更新业务逻辑就好了，而不是可能必须更新与一个应用程序服务通信的 100 个客户端应用程序。这还意味着业务对象还必须具有 DTO 对象的所有获取/设置例程。

我希望这是有道理的。任何想法将不胜感激:-)

Answer 1

我最初的想法是 - 你的实际问题是什么？因为据我所知，你没有做错任何事。

是的 - 将多个对象放入 DTO 中，然后将其序列化以在客户端/服务器之间“通过线路”传输，这对我来说听起来很正确。

是的 - 拥有类型/业务对象的共享库就可以了；我假设它们只不过是没有逻辑的真正“愚蠢”的数据结构，并且它们不会经常改变。

<块引用>

所以我认为我需要在某种程度上从数据库模型中抽象出来。

是的。您可以在客户端和服务器之间执行相同的操作。如果您使用的是 Microsoft 平台/.Net，您可以使用 WCF，它允许不同类型的绑定，因此不再需要手动序列化。

<块引用>

问题是我在两个地方有业务逻辑

，在两个地方有它并不理想 - 但它确实有一些优点。在客户端复制一些业务逻辑（我在这里想到“验证”规则）的一个优点是，UI 可以为用户提供更具交互性的体验，因为他们不必等待来回告诉他们不能将自己的姓氏添加到电话号码字段中。您仍然需要在服务器端提供适当的验证和完整的业务规则：可以说是“纵深防御”。