Java 持久性 : Design with it in mind from the beginning or add in later?

Question

我现在正在做一些事情，比如编写类和它们的单元测试——业务逻辑。毫无疑问，我需要有类似 JPA 的东西来允许我存储这些类并从数据库初始化应用程序。我也知道我需要在一个事务中做很多操作。

我的问题是，先实现业务逻辑然后再担心持久性是否有意义，或者我是在自找麻烦——也许我应该从一开始就在我的设计中加入持久性:它可能以后加进去很难吗？或者是否有一种业务逻辑可以完全忽略持久性的方法？我猜不是的原因是持久类需要注释。

无论如何，我本可以更简洁一些——也许标题已经说明了一切。

干杯。

Answer 1

将实现与特定技术隔离开来是最佳做法。通常，最好不要准备使用 JPA 来开发应用程序。

为此，您可以为业务逻辑使用单独的领域模型。域对象应该映射到/从业务逻辑层边界的持久表示。

Domain driven design , clean architecture , hexagonal architecture (可能还有其他一些)是强调业务领域与框架分离的不同但密切相关的方法。

主要好处是关注点完全分离。通过不依赖于数据库的非常快速的测试，您可以为您的代码实现非常好的可测试性。您还可以切换持久性技术(如果您愿意，可以使用内存中的数据库或平面文件)，而痛苦要小得多。

缺点是您必须定义域类和持久类之间的边界映射。

话虽如此，有时完全接受一个框架可以有它自己的好处，但必须权衡干净的设计。在创建一个简单的一次性 Web 应用程序时，完全使用 JPA 实体是有意义的 - 甚至使用附加的 JPA 实体在 UI 中显示 - 这称为“事务 View ”。

预期的好处是简单 - 如果没有逻辑可言，有时引入“业务逻辑”层是没有用的。