Java持久性：从一开始就考虑它，还是以后再添加？

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

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

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

---

干杯。

将实现与特定技术隔离是最佳实践。一般来说，开发应用程序时最好不要准备使用JPA

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

，（可能还有其他一些）是不同但密切相关的方法，强调业务领域与框架的分离

主要的好处是清晰地分离关注点。您可以通过不依赖数据库的非常快速的测试来实现代码的非常好的可测试性。您还可以切换持久性技术（如果您愿意，可以在mem-DBs或平面文件中使用），而痛苦要小得多

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

话虽如此，有时完全接受一个框架会有它自己的好处，必须与干净的设计进行权衡。当创建一个简单、一次性的webapp时，始终使用JPA实体是有意义的——甚至使用附加的JPA实体在UI中显示——这称为“事务视图”

---

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

感谢您的快速响应。一个小问题：你是说“正交”而不是“六角形”吗？我遇到的问题是，我实际上必须在某个时候通过添加注释来修改业务逻辑类，以实现持久性。我还将定义事务。你似乎在说，是的，但这可以在以后做——不要在我实现业务逻辑时做。这就是我希望能起作用的。不客气-我的意思是六边形-这是Alistair Cockburn的一个概念-请查看添加的链接我预先知道这将是一个相当复杂的应用程序，确实会有业务层。持久性和事务将是核心。业务逻辑是否可以忽略事务？例如，如果一个帐户将资金转移到另一个帐户，那么明显的交易似乎是业务逻辑的一部分——但可能一个帐户减少其余额，另一个帐户增加其余额是业务逻辑，合并这两个操作的交易可以稍后添加。我将进行实验。再次感谢。您的业务逻辑中仍然可以有事务，但是您需要委托持久性关注点。是的，你将被迫改变设计，所以请通过阅读和游戏来准备。这种方法引入了自己的开销，并不是一个灵丹妙药，但值得尝试，特别是对于复杂的应用程序。熟悉这些概念可以帮你省去一些麻烦。Godspeed.阅读有关DomainDrivenDesign和Whirlpool建模的信息-应该有帮助：）