Question

好的，

这是一个更多的原则问题，而不是事实。

我有一个在客户端和服务器上都使用的数据结构。

但是，在服务器端，我想要从某种数据存储区创建客户端的功能（目前SQL，它曾经是序列化数据，但没关系）。

最初我有一个名为'Datastore'的巨型类，它有静态方法来检索任何存储的对象。

虽然并不可怕，但这并不完全是OO，并且它不完全可扩展。

所以我考虑将这些静态方法移动到数据结构本身。但是，这意味着共享客户端库然后知道如何从我的数据存储中检索对象 - 这有点愚蠢。

所以我现在正在为新数据存储区中的每个对象创建新类，每个对象都包含从数据存储中检索一个对象的静态方法。

我的问题是，如何表示这些数据管理器类与它们检索的对象之间的关系？

从功能上讲，没关系。静态方法工作正常。但我想向未来的我和其他未来的开发人员表明，数据检索器类和对象类是紧密相连的。

我的第一个想法是让数据检索器扩展数据结构。但是，这需要声明默认构造函数并暗示可以实例化类 - 它可以，但为什么会这样？

我的第二个想法是让数据检索器扩展数据结构，但是是抽象的。这标志着与其他开发者的紧密关系，并且还明确表示只添加了新方法，没有新的领域。

但是，使用抽象类扩展具体类似乎很奇怪，Java仍然让我创建默认构造函数。

Answer 1

我的问题是，如何表示这些数据管理器类与它们检索的对象之间的关系？

这是一个标准的行业问题：如何将数据从数据库导入应用程序。常见的解决方案是使用 DAO模式，即使数据访问对象（DAO）负责从数据库中检索对象。

如果您要检索员工的个人信息，工资等，您可以拥有一个EmployeeDAO类，该类将从相应的表中检索它。如果您要检索公司的利润，地点，员工数量，您可以使用CompanyDAO类从数据库中检索此对象。

除此之外，还可以是服务层，用于执行业务逻辑;还有一个DAO管理器，用于实例化DAO并返回对任何需要它们的类的引用。

Answer 2

您仍然可以合并Repository Design Pattern和DAO Pattern的概念，使应用程序处于更简洁的抽象级别。存储库充当域级抽象。例如：

public class EmployeeBO implements EmployeeRepository { // implementation of a Business Object Domain-model

     @Inject
     private EmployeeDAO employeeDAO; // really implementation of data access


     @Override
     public  boolean createEmployee(String name){ // domain-oriented method
          // ... some validation
          employeeDAO.save(new Employee(name)); // really data access/persistence implementation
     }

}

Java将静态方法添加到类中

2 个答案: