应用模型管理问题

Question

考虑使用SQL数据库的以下类型的Java / Spring应用程序：

• 有多个数据实体类型(约100)，它们之间有关系。
• 这些实体被查看、编辑或暴露在API中，这种情况经常发生在几种实体类型(联合)中。

目前的方法使用三层：

• 一个数据层，它查询表，并使用与数据库匹配的1:1实体。
• 一个服务层来执行业务逻辑，并根据需要调用数据层。
• 控制器层-向客户端代码和API公开操作。

与处理模型有关的问题是：

1. 每个层都应该有自己的模型/实体类吗？如果是，如何最好地处理跨层的模型复制/合并？
2. 有时，在服务层，实体可能需要在一种情况下填充某些字段，而在其他情况下则不需要填充某些字段。对于这两种情况，应该有两个模型类吗？(以确保可以依赖服务提供的字段)
3. 鉴于实体数目众多，是否值得一致地以同样的方式处理上述问题，而不论所涉及的任何额外复杂性？

Answer 1

1. 我不认为每个层都应该有自己的实体类。这样做会使类的数量成倍增加，并增加复杂性，而不会带来任何真正的好处。有时，服务层中的一个概念不能很好地映射到关系DB (或其他持久性技术)，因此创建不同的实体类是明智的，但大多数情况下，它是不必要的，您可以为所有层创建相同的实体类。但请记住，事情会发生变化，一个层的需求将与其他层不同(例如，您必须在控制器层保留旧的契约)--这时您需要准备为不同的用例创建不同的实体类。如果您对所有层使用一个实体，更改将影响所有层-例如重命名属性可能会破坏控制器的契约。
2. 这通常是出于性能原因。最好的做法是尽可能避免这种情况--当心过早优化的危险。但有时这是必要的，然后很难给出一个答案--如果这是使用这个不完整实体的一个特殊情况，那么您可能只需要记录它就可以了。如果它被更频繁地使用，您应该为此创建特殊的实体类，否则您将陷入随后的复杂性中。
3. 就我个人而言，我认为最好一个接一个地处理这件事。实体将以不同的方式发展，试图以统一的方式处理它们将带来大量的开销和无用的复杂性。

因此，我的建议是，只有在每个层都有必要/有意义时才创建实体。但是，您需要记住结果，并在需要时随时准备对实体类进行划分。

此外，要小心交易。很容易忘记您是否处于事务上下文中，特别是当您在任何地方使用相同的实体类时。根据我的经验，有明确的事务划分通常是好的--即整个服务层是事务性的(默认情况下)，外部的一切(控制器、任务等等)。不是。