我正在“springwrapping”的遗留数据库有 Id，它们是字符串，并且会泄露一些信息。例如，UserId 看起来像“DK-6715-00001”，表示丹麦的用户，邮政编码 6715。它被封装到企业应用程序中，需要保留，我的实体在他们的 setter 方法中验证这一点。
但是，User 也有 country 和 postal code 字段，所以当设置 bean 的 Id 时，它也可以设置 country 和 postal code。为此，它需要 CountryService 查找 Dk 是 Denmark Country 对象，并在 PostalService 中用新找到的 Country 对象查找 6715。
首先，我可以把它连接起来，以便我可以从我的 Entity 对象访问 CountryService 和 PostalService 吗？（在我的 bean 定义中，实体是在服务对象之前定义的）其次，这应该违反任何好的设计原则。有没有更好的设计让我的实体携带对服务 bean 的引用？
干杯
尼克
如果您正在寻找设计建议，这是我的 0.02 美元：实体不应引用服务 bean。服务应该在实体上运行，而不是相反。因此，如果您发现需要对某个实体类中的服务进行引用，则可能表明该实体类内部存在过多的业务逻辑。根据经验，业务逻辑在实体类中是可以的，只要逻辑只处理单个对象或者非常简单（例如，equals方法）。但如果业务逻辑是“跨实体”（涉及多个实体对象），则应该在服务 bean 中实现。
如果您不在乎我的想法而只想让您的设计工作：您可以使用 AspectJ 在实体中注入 Spring bean 引用。我相信它需要 AsjectJ 的额外编译步骤和/或运行时支持。使用 Spring 本身无法做到这一点，因为在使用Spring 不支持的new关键字创建实体对象时需要注入服务对象。
听起来这是应该放在控制器中的逻辑。
该 UserCreationController（可能添加 UserService）应该引用那些 CountryService 或 PostalService，以及（可能）JdbcService 或 HibernateService，具体取决于您的应用程序。
实体类（或 POJO）应该在简单方面犯错。
编辑：这是将两者分开的业务逻辑。控制器接收表单数据，将其映射到您的域实体，调用您的业务逻辑（服务/s）并根据结果决定用户应该去哪里。
感谢您的输入。我已经确定这确实是一个设计缺陷，并且我对此的想法是错误的。我应该完全删除 Id 属性的 setter 方法，并为其设置一个 getter，然后为构成 Id 的其他属性设置 setter 和 getter。这样一来，我就不必费力地确保Id格式正确，也不必访问任何服务。
干杯
尼克