Spring Entity 使用服务，可能的设计缺陷，但仍然答案

【问题标题】：Spring Entity to use Service, possible design flaw, but stillSpring Entity 使用服务，可能的设计缺陷，但仍然
【发布时间】：2009-09-30 14:26:12
【问题描述】：

我正在“springwrapping”的旧数据库具有 Id，它们是字符串并且会泄露一些信息。例如，UserId 看起来像“DK-6715-00001”，意思是丹麦的用户，邮政编码 6715。它被包装到企业应用程序中，需要保留，我的实体在他们的 setter 方法中验证这一点。

但是，User 也有字段 country 和 postal code，所以当设置 bean 的 Id 时，还不如设置 country 和 postal code。为此，它需要 CountryService 查找 Dk 是丹麦 Country 对象，并在 PostalService 中使用新找到的 Country 对象查找 6715。

首先，我可以把它连接起来，以便我可以从我的 Entity 对象访问 CountryService 和 PostalService 吗？（在我的 bean 定义中，实体是在服务对象之前定义的）其次，这应该违反任何好的设计原则。有没有更好的设计可以让我的实体携带对服务 bean 的引用？

干杯

尼克

【问题讨论】：

标签： java spring service entity

【解决方案1】：

如果您正在寻找设计建议，这是我的 0.02 美元：实体不应引用服务 bean。服务应该在实体上运行，而不是相反。因此，如果您发现需要对某个实体类中的服务进行引用，则可能表明该实体类内部存在过多的业务逻辑。根据经验，业务逻辑在实体类中是可以的，只要逻辑只处理单个对象或非常简单（例如 equals 方法）。但如果业务逻辑是“跨实体”（涉及多个实体对象），则应该在服务 bean 中实现。

如果您不在乎我的想法而只想让您的设计工作：您可以使用 AspectJ 在实体中注入 Spring bean 引用。我相信它需要 AsjectJ 的额外编译步骤和/或运行时支持。使用 Spring 本身无法做到这一点，因为在创建实体对象时需要使用 Spring 不支持的 new 关键字来注入服务对象。

【讨论】：

这是 AspectJ 的编译步骤——“正常”AOP 在运行时完成。
我同样在寻找两个答案，如果这是我必须走的路线，我该怎么做，还有什么设计更可取。所以从您的设计角度来看，“创建一个新的丹麦用户”将是一个商业声明，而“创建一个新用户”将是一个实体声明？
@niklassaers - 是的，我当然可以想象一个 UserAccountService 可以创建用户、分配角色、重置密码等。“创建用户”用例的一部分可能涉及查找补充数据，例如国家/地区如果这是您需要在用户 ID 中出现的代码。
我所指的普通 AOP 是 Spring AOP API。这种魔法发生在运行时。 AspectJ 的独特之处在于它仅在编译时使用字节码编织来完成相同的事情。
您可以进行加载时编织，因此 AspectJ 不一定是额外的编译步骤。

【解决方案2】：

听起来这是应该放在控制器中的逻辑。

UserCreationController（可能添加 UserService）应该引用那些 CountryService 或 PostalService，以及（可能）JdbcService 或 HibernateService，具体取决于您的应用程序。

实体类（或 POJO）应该在简单方面犯错。

编辑：这是将两者分开的业务逻辑。控制器接收表单数据，将其映射到您的域实体，调用您的业务逻辑（服务/s）并根据结果决定用户应该去哪里。

【讨论】：

控制器和服务之间的区别是什么？我一直认为控制器是我的界面与我的服务相遇的地方，所以我阅读你的答案的方式我认为你会在服务中拥有它？
Nathan：您还有其他推荐的 Java '普通' AOP 实现吗？

【解决方案3】：

感谢您的意见。我已经确定这确实是一个设计缺陷，并且我对此的想法是错误的。我应该完全删除 Id 属性的 setter 方法，并为其设置一个 getter，然后为构成 Id 的其他属性设置 setter 和 getter。这样一来，我就不用费力地确保Id格式正确，也不必访问任何服务。

干杯

尼克

【讨论】：