Java 架构：在不污染POJO的情况下操作模型的最佳实践？而且没有到处重复锅炉铭牌代码

这是我们经常遇到的问题。必须有一些最佳实践来解决这个问题

简化问题 操作POJO的公共代码最好放在哪里

以便：

• POJO只有属性和getter/setter
• 相同的模型操作代码不会“到处”重复
• 很清楚哪些类负责操纵模型

---

背景 我们有一个定义域的模式。由此，我们生成了一个由来自JAXB的简单对象（POJO）组成的“纯”模型

在使用该模型时，团队中的几个开发人员已经创建了锅炉板代码来访问和操作该模型。它在许多地方都是“撒”的。有些人创建了包装器对象，该对象将模型实例子类化并添加功能。其他人创建了外部实用程序类。我希望统一此代码，使其不再“到处散播”。理想情况下，逻辑可以包含在某类对象中，这些对象显然负责模型的一般操作。

例子 让我们以杂货店为例。模型对象由以下内容组成：

产品、过道、货架、员工、工作时间表、供应商

常见的模型操作包括以下内容：

FindManager工作日（天，日程），FindDaisleForProduct（苹果），countItemsOnShelf（topShelf），product.isModified（），从供应商（苹果，供应商）移除product

我们不想用

removeProductFromVendor

这样的函数“污染”我们的供应商POJO。同样，我们不一定要扩展每个模型对象，只需添加

isModified

属性，这样GUI就可以知道“启用/禁用”保存按钮

还是我们

总结 一旦一个模型对象在内存中，谁应该负责操作它——例如，遍历“今天值班的员工”列表，找到一个“经理”

在这些情况下，数据库调用是多余的，因为我们已经在内存中拥有了所需的一切（例如：我们已经查询了数据存储，需要在整个应用程序中处理结果对象）理想情况下，此代码可用于任何对象，例如，拥有员工列表的对象。

---

就最佳实践而言，哪里是放置静态方法的理想位置：

public static Employee find manager（列出员工职责）

它将遍历员工列表（POJO）并返回第一个列表，其中
employee.title.toLowerCase（）包含（“经理”）

如果一个团队使用这个示例对象模型，几个人会编写这样的函数。有哪些最佳实践可以抓住这一责任，从而使POJO保持“纯净”，而相同的锅炉板代码不会“到处散播”。据我所知，听起来您的POJO模型只是数据（或者您希望保持这种方式）。为什么不创建facade对象，比如
Query
、
Count
或其他命名功能分组，以隐藏操纵算法的所有相关机制

它不会污染POJO，这听起来是你想要避免的。
鉴于你的POJO对象来自一家供应商，我理解你不愿意为它们添加功能，而且你显然不希望在你的项目中随意散布代码

听起来像是一组Decorator子类的工作，或者像Ken建议的那样，facades

我喜欢这里的decorators，因为您只需通过decorator类的名称来引用您的供应商pojo，这样就可以在一个地方添加行为（isModified、searchByName等）。
我猜对于find*之类的操作，它们属于服务类；但是对于“isModified”，服务类没有帮助，它必须在pojo本身中，除非修改也通过服务类进行。相应的服务类可以在集合中维护此类对象的状态。
在类似的情况下，我们决定将所有“功能”（行为）提升为对象模型的第一类公民

所以我们现在有了不同的包，一个只有POJO，一个有函数对象（又名处理器）在这些对象上应用函数

例如，作为POJO的合同对象，以及作为处理器的ContractBilling、ContractFinder、ContractCloser等。它们中的大多数都是根据合同或合同清单运作的

我们发现它非常有效，这迫使我们正确地记录系统中的所有内容（因为函数已经成为对象）。这种方法在体系结构上的好处是令人敬畏的，尽管我们在这种设计中有更多的对象，但我们有更小的类，更易于管理、理解和发展。
尽管这个问题目前才1岁，但希望它对其他人可能会有所帮助。
因此，您的愿意将POJO和behavour分开，这样这些声明就有了位置：
a） POJO只有属性和getter/setter，
b） 重复使用相同的模型操纵代码，
c） 很清楚哪些类负责操纵模型
被广泛认可，并且正在通过将应用程序拆分到层来实现，即：

您的POJO-是普通模型，包含字段/属性和getter/setter
将与模型上的操作相关的业务逻辑放在服务层中-在您的案例中，与模型上的操作相关的所有内容（例如，EmployeeService）都可以在EmployeeService中分配（因此可以在许多地方重用）
与p有关的一切