1

我们有一个在控制器/服务/DAO 架构上用 Java 开发的经典订单管理应用程序。数据对象是表示数据库中数据的 POJO。基本上我们有 1 个类映射数据库中的 1 个表，但我们不使用任何 ORM 或实体机制这些数据对象在所有层之间传递，以通过 Web GUI 创建/修改/获取订单。该应用程序还有一个 WebService 层，允许外部系统通过 SOAP 管理这些订单。WebService 层依赖于 Service 层来确保 WebService 和 GUI 之间使用相同的逻辑。

我们尝试使 WebServices API 尽可能稳定，但是由于我们目前使用数据对象作为 WebService 方法的参数，因此该 API 可能会经常更改（至少每次我们拥有或修改数据库中的任何字段时） . 此外，我们希望向 WebService 客户端隐藏一些复杂的数据库结构。例如，数据库包含多个我们希望对客户隐藏的字段。

具体问题：

  • 通过客户端 API 隐藏数据库结构和字段常用什么样的设计模式？

  • 是否有任何好的做法来处理公共方法参数和内部数据对象之间的“映射”？

  • 数据传输对象是我问题的答案吗？

4

3 回答 3

2

您不应该跨进程边界传递数据对象。它使您的应用程序变得脆弱，并保证每次进行架构更改时都会进行大量返工。我的建议是这样的：

- 数据访问层应该就是：处理创建、读取、更新和删除数据库对象。DAL 的用户必须知道数据库的工作原理才能使用它。

ex（在伪代码中）：

Person = {
PERSON_ID:'1234567jksjgkhsduw0909wueioksgt',
FIRST_NAME:'CHRIS',
LAST_NAME:'MCCALL',
TITLE:'',
GENDER:'M',
LAST_NAME_SUFFIX:null,
Addresses = [{ADDRESS_ID:1234,...}]
}

等 - 服务层转换数据库模式以隐藏复杂性，并对尝试使用这些数据制作应用程序的开发人员真正有用的内容发表意见

前任：

Person = {
name:'Chris McCall',
primary_address:'123 Main St',
secondary_address:null
}

您可以决定是否包含 ID。您可能决定更改字段名称的大小写，并且您可能会将数据投影到对应用程序开发人员更有意义并且比您的数据库架构更稳定的表单中。也许你留下了一堆东西，所以通过网络传输的数据更少。类似的东西。

您的 DBA 的任务是创建一个性能良好的数据库，并通过规范化最大化存储。这是与服务层不同的目标，服务层不期望其调用的结果被持久化。

不同的架构对视图模型有不同的名称（这就是我所说的）。DTO 是另一个名称。

于 2012-12-13T16:34:43.213 回答
0

我们尝试使 WebServices API 尽可能稳定，但是由于我们的数据对象被用作 WebService 方法的参数，因此该 API 可能会经常更改

你已经走错路了。Web 服务是以与平台无关的方式实现互操作性和集成。
传递给 Web 服务的所有对象都应该是“数据持有者”，并且应该与您的业务逻辑无关。您应该有转换器将这些“数据持有者”映射到您的应用程序所需的实际类

于 2012-12-13T16:44:55.157 回答
-2

回答我自己的问题：

我们显然面临着将结构化数据暴露给公共 API 的问题。这些数据来自内部管理的域模型（数据对象），但域模型不得直接通过公共 API 公开。

相反，必须创建和维护另一组类，通常称为数据传输对象 (DTO) 或视图模型，以用作公共 API 的输入/输出参数。使用这样的 DTO，域模型可以在不修改公共 API 的情况下进行更改，并且公共 API 可以以非常可控的方式进行更改。

某些映射（也称为绑定）必须在应用程序中维护在域模型和 DTO 之间。经常是双向的。可以在此处找到大量 Java 映射器/绑定器库

于 2012-12-14T15:24:21.473 回答