避免贫血域

我在一个看起来像“国家/省/市”的数据库中有一列，例如， “加拿大/安大略/多伦多”。我需要分割它们并将它们映射到3个独立的Java Bean属性中。避免贫血域

我想知道在哪里最好做到这一点？

（1）DAO作为检索行（2）域（豆）作为制定者是吸气剂被称为（3）SQL函数到查询解析行（4）使用ResultSetExtractor类

我倾向于＃2或＃4，因为“贫血域”反模式似乎表明Bean的是这个合适的地方。

来源

2012-07-09 EdgeCase

什么是“DAO”？ – Gabe 2012-07-09 19:58:09

@Gabe数据访问对象。商业软件世界中使用的标准模式。 – 2012-07-09 19:58:39

恕我直言，最好的地方是数据库。我会将该列分成表格中的3列，并按列存储一个信息。

如果这是真的不遗留原因的选项，我的确会做它在直接域对象。这是可以直接封装在域对象中而不会对其他实体产生任何影响的行为。

来源

2012-07-09 19:28:33

我想避免数据库的原因是我担心分隔的路径项可能会更改为包含更多或更少的节点，我希望灵活性能够适应。即第二个节点可能不总是省，至少在某些情况下，所以我可能需要应用逻辑来确定。我越看这个，我喜欢使用ResultSetExtractor（Spring JDBC）。它不完全是豆，它不是那个DAO。它位于二者中间。 – EdgeCase 2012-07-09 19:40:53

路径越复杂，您需要的规格化数据模型越多，恕我直言。否则，您最终会将XML，JSON或序列化对象存储在单个列中，并且您将无法再查询您的数据。一列=一个信息。 – 2012-07-09 19:48:31

如果重新设计数据库的选项仍然对您开放，那么您应该肯定**更喜欢此选项。没有什么能够打败拥有结构良好模型的优势。我认为我们应该讨论其他的选择只会失败。 – 2012-07-09 20:12:48

我不确定我是否同意你的观点;你可能会争辩说，域实体不需要受数据表示的影响。
如果您的数据库布局不同，您是否会考虑让setter和getters拥有一个bean？
我的答案是'不'，那么你可能不想要那个选项。

就个人而言，我认为，如果你有一个数据访问层，这是其求职到transaform数据表示成域表现的一部分。

来源

2012-07-09 19:23:35

作为反模式的贫血领域的资格并没有达到现实。在商业软件中，您实际上需要完全分离功能和数据模型。面向对象的业务逻辑没有太多可提供的东西。事实上，它要求将每个函数分派到一个对象上，导致巨大且不可维护的对象图。没有人将图形构建分解为自动装配IoC框架，甚至没有人试图构建它们。 – 2012-07-09 19:51:21

再一次 - 你说出你的观点是事实。 – 2012-07-09 19:53:37

+1 DAO是做翻译的最佳地点。域对象应该反映真正的业务模型，而不是持久性模型（在许多情况下，由于传统原因，这种模式是离开的）。 – casablanca 2012-07-10 04:11:15

如果一个JPA @Entity那么我会直接映射的私人字符串到数据库列，然后进行公开干将那套访问它。这样，域模型的使用者就可以与连接字符串的内部/数据库表示隔离。或者，您可以在@PostLoad回调中进行翻译。（上坚持反向翻译可以在@PrePersist回调来完成。）

来源

2012-07-09 19:35:24 wrschneider

是不是你的1和4实际上是同一个解决方案吗？我猜你会在你的DAO代码中使用ResultSetExtractor。使用SQL函数并不是一个坏主意，因为它可以从其他技术中重用，但存在维护问题。

我不会建议推迟解析，直到得到的时间，因为它不是从性能方面不错，可以让做这些领域的其他任务时，你的人生复杂化了。如果你的豆子已经有了三个区域，它会更干净。

来源

2012-07-09 20:02:16

是的，如果我的DAO和提取器在同一个班级，但是我已经把他们分开 - 无论是对还是错。请参阅我对上述问题的回复。 – EdgeCase 2012-07-09 20:47:34

回答

相关问题