将行为嵌入实体Bean是一种好习惯吗？

Question

虽然我的Java应用程序很小并且做了简单的事情,但我很高兴使用纯SQL,而像Glassfish这样的应用程序服务器使连接管理变得非常简单.在我了解了JPA和EJB之后,我决定重构我的项目以使它们使用这些很酷的东西,但面临的问题更多的是关于设计而不是编程:

将行为嵌入实体Bean是一种好的做法,还是只应保存数据？

我已经阅读了很多手册和教程,但他们主要回答我如何使用它们,而不是我应该如何使用它们来满足良好的设计要求.

例如,给定2个类:User并且Location,它们都是实体bean.A user可以存储locations的集合,使用JPA可以轻松实现.但是,如果我想用一些功能填充这些类,例如计算到另一个用户或位置的距离的方法,找到它们的路径交叉点,计算user一天运行的距离,等等.如果我在bean本身实现这样的功能,或者我应该使用特殊的装饰器和带有大量静态方法的辅助类来实现我的目标,它会是一个"好的设计"吗？

Answer 1

您正在尝试实施域驱动（DD）方法。它对于某些应用程序很有用，但往往与 SOA 架构相反。SOA 概念很广泛，经过充分验证，甚至是现在的热门话题，另请参阅微服务（又名 SOA v2.0）

如果您使用 Java EE，则可以使用网关模式来实现SOA 的DD 或边界控制实体。

现在几点：

• 将实体 Bean 作为普通对象使用，而不仅仅是作为数据表示，这是一个好习惯吗？对于DD来说这是可以的并且值得鼓励。对于 SOA 来说，则不然。

• DD 设计的扩展性会比 SOA 更好吗？取决于应用程序（有状态 bean 的内存占用很小且易于管理）。只有压力测试才能给您带来良好的洞察力。

• 我可以基于 DD 创建一个原型，然后在需要时传递给 SOA 吗？为什么不呢？也许有一个硬重构阶段，但这是可能的。DD 原型的构建速度更快。

• 与不可变对象相关的任何安全问题值得一提？不可变对象是为了避免并发问题（无需更改，没有人受到伤害）。网关模式基于事务和 EJB（具有继承的安全模型）。所以总的来说，没有问题。

• 我需要使用 JPA 进行获取/设置吗？不，不是强制性的。

• 我可以使用 JPA 创建不可变对象吗？是的，只需一个构造函数和私有属性（正确注释）即可完成。

• 我可以在 SOA 项目的实体中混合某些行为吗？好吧，我将只添加一些不需要向实体添加实体管理器的特定方法，这意味着简单的操作不适用于庞大的对象图。整个项目的一致性非常重要。

• 测试怎么样？两种解决方案都具有高度可测试性。尽管 SOA 和微服务迫使您将应用程序分解成小块，这可能会帮助您避免创建整体（大泥球）应用程序。

我讨厌地方性模型看起来多么糟糕，但至少有效。