我已经习惯使用像 JPA 这样的框架来在数据库行和 Java 对象之间进行对象关系映射。
但是，在我的公司中，我们使用 ORM 的专有框架，它不使用实体类来表示实体，而只是一个 java.util.Map 类，其中数据库列值映射到其名称.
通常，这样的 map 也可以用作表示层呈现表单的模型。再次发布表单会将参数作为映射注入(inject)到处理程序方法中。这是 2000 年代初的旧框架。
即使认为在实体类上使用映射听起来像是过时的和反模式的，但我实际上喜欢这个模型的“动态”本质。在 map 传递到表示层之前，您可以轻松地将任何数据添加到业务逻辑层中的 map ，并且只需更改模板本身即可成为表单的一部分。如有必要，它允许您用任何东西来增强任何实体。如果您必须在某些条件下显示某个字段的某些通知，那么这最终很有用。您只需检查条件，如有必要，将通知添加到 map ，然后在模板中渲染它(如果 map 中存在)。如果我使用实体类，我将需要使用属性来重构实体类接口(interface)，而该属性甚至不是实体的真实属性。业务逻辑充满了这些特殊条件，并且它们在不断演变。
这种想法很危险吗——我是否陷入了反模式？或者在复杂的业务领域使用这种模式是否合理，这种模式有名称吗？
最佳答案
我不知道适合您描述的模式，但使用 Map相对于实体类也有缺点。
You can easily add any data to the map in the business logic layer before map gets passed to the presentation tier, and it becomes part of the form with only changes to the template itself.
你所看到的优势意味着你永远无法确定Map处于哪个状态。是。如果您通过服务 1 加载实体，则 map 可能包含一些值。如果您通过另一个服务 2 加载相同的实体，它可能不包含某些值。 Map的状态是特定于用例的。
由于您使用的是Map这也意味着从客户的角度来看，每个属性都具有相同的类型，例如Map<String, Object> 。因此，如果您在代码中看到实体映射，您还必须知道它的类型。不知道这会很困难，例如计算订单总数。
只要您是唯一负责该代码的人并且您了解所有Map说你会认为它灵活且快速。如果您有一段时间没有使用此类代码，您可能会忘记 Map 的不同状态。可以有。然后，您必须检查每个用例的整个代码，看看某些代码是否添加或删除了属性，或者只是替换了属性类型。
因此，请尝试从文档角度考虑该设计。专用实体类的一大优点是它是有名称的。您可以为类指定名称并赋予其含义。例如
public class PlacedOrder { ... }
public class Refund { ... }
您还可以轻松地将 javadoc 添加到类中，以提供有关该类在您的上下文中的含义的更详细信息。这通常称为 Ubiquitous Language 。我经常只使用术语“领域语言”，因为它更容易讲。
根据我的经验，这种设计通常会导致系统难以维护。一开始，当代码库很小时，你的速度真的很快。但这并不奇怪，因为您通常可以通过不应用 clean code 来节省文档时间。原则。
由于编译器无法检查类型，因此您只能在运行时发现类型问题。这意味着您必须创建一个大的 test harness ，因为测试还必须发现编译器会报告的错误。或者你只是开发试错的方式，但这不是我的方式，也不能让我满意。
关于java - 这个 ORM 模式叫什么，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48354022/