0

我正在实现核心 J2EE 模式中指定的 DAO 模式。在我的项目中，我有 3 个模块：core layer，它使用DAO-API layer，由我的Service Provider DAO-MySQL layer实现。

我对s的设计和使用有疑问TransferObject：

1a)TransferObject与它们的等效“业务层”类相比，s 非常冗余是否正常，或者“业务层”类是TransferObjects？

例如，如果在我core layer的课程中：

public class Customer {
    private int id;
    private String lname;
    ...
    //various methods here, plus getters/setters
}

在DAO-API layer中，我将拥有：

public class CustomerTO implements Serializable {
    private int id;
    private String lname;
    ....
    //getters/setters here
}

Customer我讨厌和之间的这种冗余CustomerTO。此外，在Core J2EE Patterns的“Example 9.5 Customer Transfer Object”中，似乎只有一个Customer类，即TransferObject.

我还看到了拥有两个类的好处，它可以让我DAO-API layer完全独立于core layer，并作为一个单独的模块提供，最终用户甚至都不知道。

=> 1b)但也许 myDAO-API layer应该是 my 的一部分，core layer并且Customer 是TransferObject?

=> 1c)或者为了避免核心业务层类与其传输对象之间的冗余，我想念什么？



2)调用DAOs方法时不使用s作为参数是否合法？TransferObject例如：

public interface CustomerDAO {
    public Collection<CustomerTO> getCustomersByNameAndCity(String name, String city);
}

或者我应该总是使用类似的东西：

public interface CustomerDAO {
    public Collection<CustomerTO> getCustomersByNameAndCity(CustomerTO to);
}

使用第一种方法有什么缺点？

4

1 回答 1

0

1a) 有 TransferObject 是否正常 是的，在您不试图限制 DTO 中要发送的信息的情况下，这是正常的。数据传输对象是用于封装数据的对象，并从一个子系统发送数据向另一个应用程序。

1b) 但也许我的 DAO-API 层应该是我的核心层的一部分，而 Customer 是 TransferObject？不，DAO 层是隐藏/封装数据库中数据的底层细节。DAO 被其他子系统用来从数据源获取数据，而不管它是如何存储/获取的。DAO 的主要目的是提供简单的 API 来对数据进行 CRUD。

1c）或者我是否想念一些东西来避免核心业务层类与其传输对象之间的冗余？如果您的 DTO 不限制任何信息，那么您可以使用业务层中的相同类。但是当您必须限制信息时，它可能会在未来的增强中引起问题。

2）调用DAOs方法时不使用TransferObjects作为参数是否合法？例如，没有人可以阻止你这样做。但有时 DTOs 属性和 DAOs 属性可能不容易相互转换。所以你必须为它添加额外的逻辑。这应该由中间人，即您的业务层来处理。

于 2013-07-10T11:44:04.803 回答