4

我想知道你们中是否有人在客户端/服务器应用程序中成功实现了 DDD，并想分享一些经验。

我们目前正在开发 Flex 的智能客户端和 Java 的后端。在服务器上，我们有一个向客户端公开的服务层，它提供 CRUD 操作以及其他一些服务方法。我知道在 DDD 中，这些服务应该是存储库，并且服务应该用于处理不适合存储库的用例。现在，我们在接口后面的客户端上模拟这些服务，并通过 IoC 容器注入实现（Webservices、RMI 等）。

所以出现了一些问题：

  • 服务器应该向客户端公开存储库还是我们需要某种外观（例如能够处理安全性）
  • 客户端是否应该实现存储库（以及一般的 DDD？）知道在客户端中，大部分逻辑与视图相关，而真正的业务逻辑存在于服务器上。与服务器的所有通信都是异步发生的，我们在客户端上有一个单线程编程模型。
  • 如何将客户端映射到服务器对象，反之亦然？我们尝试了 DTO，但又恢复为公开对象的状态并直接映射到它们。我知道这被认为是不好的做法，但它为我们节省了大量时间）

总的来说，我认为新一代应用程序将随着 Flex、Silverlight、JavaFX 的发展而出现，我很好奇 DDD 是如何融入其中的。

4

1 回答 1

2
  1. 我不会直接向客户端公开存储库。您提到的第一个大问题是安全性：您不能信任客户端，因此您不能将数据访问 API 暴露给潜在的敌对客户端。
  2. 使用服务器上的服务包装您的存储库，并在处理远程通信的客户端中创建一个瘦委托层。
  3. 暴露您的实体不一定是一种不好的做法，只是当您开始考虑延迟加载、通过客户端不需要的线路发送数据等因素时，它会变得有问题。如果您编写一个包装一个或更多实体和委托 get/set 调用实际上可以非常快速地构建 DTO 层，尤其是使用大多数 IDE 中可用的代码生成。

所有这一切的关键在于，一组模式实际上应该只适用于应用程序的一部分，而不是整个应用程序。您在域模型中拥有丰富的逻辑并使用存储库作为 DDD 的一部分进行数据访问这一事实不应以任何方式影响客户端。从概念上讲，我构建的 RIA 具有三层：

  1. 客户端使用诸如 MVC、MVP 或 MVVM 之类的东西来呈现 UI。模型层最终调用...

  2. 我可以称之为“集成层”。这是客户端和服务器上都存在的服务和数据对象的合同，以允许两者进行协调。通常，UI 设计驱动这一层，以便 (A) 仅将客户端需要的数据传递给它，并且 (B) 数据访问可以是粗粒度的，即“对这组所需的所有状态进行一个方法调用用户界面。

  3. 服务器使用任何它想要处理的业务逻辑和数据访问。这可能是 DDD 或更老派的东西，例如使用数据库中的存储过程和大量“ResultSet”或“DataTable”对象构建的数据层。

关键是客户端和服务器都是非常不同的动物，它们需要独立变化。为了做到这一点，您需要一个介于 UI 需求和服务器上可能需要的实际情况之间的公平折衷层。

Silverlight/WPF 和 JavaFX 与 Flex + 任何东西相比的一大优势是您可以在前两个中使用大量逻辑，因为您在应用程序的两侧都有相同的 VM。Flex 是最好的 UI 技术，但它缺少可以更有效地共享和重用代码的服务器组件。

于 2009-04-05T20:44:11.317 回答