【问题标题】:Chain of responsibility with large configs大型配置的责任链
【发布时间】:2013-02-19 03:13:03
【问题描述】:

我正在为我的管道使用责任链设计模式。我发现的一个问题是,随着我添加更多链,配置对象变得越来越大。本质上,我的配置对象正在变成一个巨大的单例。有没有有效的方法来处理这种情况?

详情:

我目前的设置是

handler.next = handler2
handler2.next = handler3
...

我通过将配置对象传递给它来使用链。

handler.HandleRequest(config)

配置对象具有处理程序所需的所有配置信息,因此随着我添加更多链而变得越来越大。

可能的解决方案:

在这篇文章中,最好的答案是使用依赖注入。

Which design patterns can be applied to the configuration settings problem?

但是,我不确定如何在不大幅改变设计的情况下在责任链设计中使用依赖注入。

有人可以帮我解决这个问题吗?谢谢!

【问题讨论】:

  • 你的链是处理配置对象(为了做什么?)还是从配置对象中提取配置?
  • 链只是从配置对象中提取配置,例如每个链的数据文件所在的位置等。配置对象负责检查用户提供的配置是否有效。跨度>
  • 还可以看看装饰器模式。它可能比责任链更容易应用(并且在添加横切关注点时特别有用)。

标签: design-patterns configuration dependency-injection chain-of-responsibility


【解决方案1】:

我认为你们试图一起做一些并不真正属于一起的事情。

如果您需要为应用程序的不同部分提取设置/配置值,为什么要尝试将它们全部读取到一个位置?

对于需要某种设置的每个组件,我更喜欢小的“设置对象”。我通常从包含所有硬编码默认值的对象开始,并在必要时从该基本设置派生。派生对象可以从任意来源读取(大部分时间是 app.config 文件,但我也使用数据库和 Web 服务)。

这是blog post that describes settings objects 的详细信息。

【讨论】:

  • 我有一个包含所有配置的配置对象的原因是因为当我运行责任链时,每个处理程序只知道哪个是下一个处理程序,因此只能传递整个配置。如果我想做依赖注入,那么我觉得这样做很尴尬,因为这意味着我将不得不大幅修改责任链的设置方式。目前,它只是返回指向下一个处理程序的指针。有什么好办法解决这个问题吗?
  • @hwasungmars 我还是不明白。你有一个大的配置对象(这个对象来自哪里?它的后备存储是什么?文件?数据库?)。您将此对象放入处理程序的管道中。每个处理程序都会在该配置对象中查找一些 sn-ps 信息,然后……用这些信息做什么?本地存储?根据这些信息创建新对象?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-02-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多