我正在研究客户端/服务器系统：
有一个数据库，一个应用服务器和一个用户界面（客户端）应用程序。应用程序服务器处理来自客户端应用程序的连接，当客户端应用程序例如通过id请求用户列表或特定对象时，客户端应用程序又与数据库进行通信。
目前我有一组数据对象，如“user”，“area”等，它们映射到数据库中的表。这些数据对象在共享库中定义，该库在编译时链接到客户端和appserver。它们继承了一个允许它们被序列化的类，因此它们可以在客户端和服务器之间传递，并且它们将“数据提供者”作为依赖注入，以允许提交发送到应用程序服务器或发送到数据库，具体取决于是否它们被用在客户端或服务器端。
当客户端应用程序的用户想要编辑用户时，它会从应用程序服务器请求该对象，使用它来使用当前值填充用户界面，允许用户编辑这些值，然后“提交”该对象返回给appserver，后者又将其提交给数据库。
这对于这个非常简单的场景来说很好，但是随着它变得越来越复杂，用户界面将需要可能由几个底层数据库对象组成的对象，所以我认为我需要从数据库模型中抽象出来在某种程度上。
在这种情况下，我不应该将我认为被称为“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，显示或更新为必要，调用“save”方法，将其序列化并发送到应用程序服务器，对其进行反序列化，创建业务对象，执行任何喜欢的操作用它（例如验证，保存到DB等）。
这意味着将所有序列化逻辑从DAL对象中删除到DTO对象，并删除我的大型业务逻辑类，并停止表示层（客户端）必须知道有关数据库结构的任何信息。
这听起来不错吗？
其他人确实建议将业务对象放在共享库中，而不是拥有数据传输对象。但问题是我在两个地方都有业务逻辑，并且能够在一个地方更新业务逻辑，而不是可能需要更新100个与一个应用程序服务通信的客户端应用程序。它还意味着业务对象必须具有DTO对象的所有get / set例程。
我希望这是有道理的。任何想法将不胜感激： - ）
答案 0 :(得分：0)
我最初的想法是 - 你的实际问题是什么？因为从我所看到的你没有做错任何事。
是的 - 将多个对象放入DTO，然后将其序列化，以便在客户端/服务器之间“通过网络”进行传输，这对我来说是正确的。
是的 - 拥有类型/业务对象的共享库很好;我假设它们只不过是没有逻辑的“哑”数据结构，而且它们不会经常改变。
所以我认为我需要在某种程度上从数据库模型中抽象出来。
是。您可以在客户端和服务器之间执行相同的操作。如果您使用的是Microsoft平台/ .Net，则可以使用WCF，它允许不同类型的绑定，因此不再需要手动序列化。
这个问题是我在2个地方有业务逻辑
是的，在两个地方有点并不理想 - 但它确实有一些优点。在客户端复制一些业务逻辑的一个优点（我在这里考虑“验证”规则）是UI可以为用户提供更多的交互式体验，因为他们不必等待往返告诉他们他们不能将姓氏添加到电话号码字段中。您仍然可以在服务器端提供适当的验证和完整的业务规则：“深度防御”可以这么说。