【问题标题】:Stateless service-centric approach vs stateful rich models无状态以服务为中心的方法与有状态的丰富模型
【发布时间】:2012-02-20 19:33:38
【问题描述】:

假设我已经定义了一组项目。这些项目必须分组到不同的集合中。例如,项目可以像

public Item {
    public int id;
    public String name;
}

集合有自己的设置,比如哪些项目属于这个集合,集合的名称是什么等等。现在所有的东西都存储在 xml 结构中。

我的第一个想法是编写以下元素:

  • xml 解析器获取集合的数据并转换为 MySet pojo

  • xml 解析器获取所有项目并转换为项目 pojos 列表

  • 无状态的类服务类说 ItemsSetCreator 计算最终的 ItemsSet 对象,其中包含基于 MySet 的集合定义和类似项目的列表

    class ItemsSetCreator {
    
         public ItemsSet createItemsSet(List<Item> items, MySet set) {
             // ...
         }
    }
    

但另一种方法是稍微丰富模型并编写如下:

  • MySet 类能够获取所有项目,根据 xml-data 对其应用内部逻辑并提供最终的 ItemsSet 作为结果

我不知道哪个更好。我知道例如 Spring 提倡更多以服务为中心的方法,但最近有很多关于避免贫血模型的讨论。

【问题讨论】:

    标签: java oop anemic-domain-model


    【解决方案1】:

    这完全取决于您的用例和粒度,因此很难明确回答您的问题。丰富模型可能是一件好事,但您也不想走下那个滑坡。

    如果我不得不在高度耦合的意大利面条代码“丰富”模型和无聊的贫血模型之间进行选择,我将不得不选择贫血模型。但是在这里使用 reductio ad absurdum 并不能解决任何问题,所以我们回到我原来的观点:这取决于你的用例。有时您希望/需要模型具有行为。有时你没有。大多数时候你都在中间的某个地方。

    作为开发人员和架构师,您的工作是找出真正需要多少行为模型。

    我要补充一点,如果您正在处理的任何事情都是分布式的,我建议不要使用有状态模型 - 在节点之间共享状态(避免死锁和竞争条件)是非常重要的。

    【讨论】:

      猜你喜欢
      • 2014-07-04
      • 2020-02-29
      • 2011-02-05
      • 1970-01-01
      • 2016-05-03
      • 1970-01-01
      • 2019-07-16
      • 2017-05-23
      • 2011-07-16
      相关资源
      最近更新 更多