我现在正在做的事情就像编写类和他们的单元测试 - 业务逻辑。毫无疑问，我需要像JPA这样的东西来允许我存储这些类并从数据库初始化应用程序。我也知道我需要在交易中做很多操作。
我的问题是，首先实现业务逻辑然后担心持久性或者我是否以这种方式提出问题是否有意义 - 或许我应该从一开始就将持久性融入我的设计中：它可能以后很难添加它？或者有一种方法，业务逻辑可以完全不知道持久性？我不猜测的原因是持久化类需要注释。
无论如何，我本来可以更简洁 - 也许标题说明了一切。
干杯。
答案 0 :(得分：3)
将实施与特定技术隔离是最佳做法。通常，在不准备使用JPA的情况下开发应用程序应该会更好。
为此，您可以为业务逻辑使用单独的域模型。域对象应映射到业务逻辑层边界的可持久表示/从中映射。
Domain driven design，clean architecture，hexagonal architecture（可能还有其他一些）是不同但密切相关的方法，强调业务领域与框架的分离。
主要好处是彻底分离关注点。您可以使用不依赖于DB的非常快速的测试来为您的代码实现非常好的可测试性。您还可以切换持久性技术（如果您愿意，可以使用内存数据库或平面文件），而且可以轻松实现。
缺点是您必须在域类和持久类之间定义边界映射。
话虽如此，有时候完全拥抱框架可以拥有自己的好处，必须权衡清洁设计。在创建简单的一次性Web应用程序时，一直使用JPA实体是有意义的 - 甚至使用附加的JPA实体在UI中显示 - 这称为“事务视图”。
预期的好处是简单 - 如果没有逻辑可言，有时在引入“业务逻辑”层时没有用。