虽然我的Java应用程序很小并做了简单的事情，但我很高兴使用纯SQL，而像Glassfish这样的应用程序服务器使连接管理变得非常简单。在我了解了JPA和EJB之后，我决定重构我的项目以使它们使用这些很酷的东西，但面临的问题更多的是关于设计而不是编程：
将行为嵌入实体Bean是一种好习惯，还是只应保存数据？
我已经阅读了很多手册和教程，但他们主要回答我 可以使用它们的方式，而不是我 的方式，以满足良好的设计要求。
例如，给定2个类：User和Location，它们都是实体bean 。 user可以存储location的集合，使用JPA可以轻松实现。但是，如果我想用一些功能填充这些类，例如计算到另一个用户或位置的距离的方法，找到它们的路径交叉点，计算user在一天中运行的距离，等等。如果我在bean本身实现这样的功能，或者我应该使用特殊的装饰器和带有大量静态方法的辅助类来实现我的目标，它会是一个“好的设计”吗？
答案 0 :(得分：4)
您正在尝试实施域驱动（DD）方法。它对某些应用程序很有用，但往往与SOA体系结构相对立。 SOA概念广泛，经过高度验证，甚至现在也是一个热门话题，另请参阅microservices（a.k.a SOA v2.0）
如果您使用的是Java EE，则可以使用Gateway pattern为SOA实现DD或Boundary-Control-Entity。
现在有些观点：
使用实体Bean作为常规对象，不仅仅是作为数据表示，这是一个好习惯吗？对于DD，这是好的和鼓励的。对于SOA，不是。
DD设计是否会比SOA更好？取决于应用程序（有状态bean的内存占用量小且易于管理）。只有压力测试才能给你很好的洞察力。
我可以创建基于DD的原型，然后在需要时传递给SOA吗？为什么不呢？，可能存在硬重构阶段，但是可能。 DD原型的构建速度更快。
关于不可变对象的任何安全问题值得提及？。不可变对象是关于避免并发问题（没有任何改变，没有人受伤）。网关模式基于事务和EJB（使用继承的安全模型）。所以一般来说，没有问题。
我是否需要使用JPA获取/设置？不，不是强制性的。
我可以使用JPA创建Immutable对象吗？是的，只是一个构造函数和私有属性（正确注释）并完成。
我可以在SOA项目的实体中混合一些行为吗？那么，我只想添加一些不需要向实体添加实体管理器的特定方法，这意味着，简单的操作，不适用于巨大的对象图。 整个项目的一致性非常重要。
测试怎么样？两种解决方案都是高度可测试的。尽管SOA和微服务迫使您以微小的碎片破坏您的应用程序，这可能有助于您避免创建一个整体（大泥球）应用程序。
我讨厌地方性模型看起来多么糟糕，但是，至少有效。
答案 1 :(得分：0)
我认为将所有这些逻辑方法放在您的实体上并不是一个好主意，也许最好的方法是从业务层获取它。
在我们的实体上获得大量瞬态字段永远不会好，所以最好的方法是创建VO（有价值对象）类。
使用VO也解决了封装问题，因为setter既不是getter也是必需的。