问题标签 [dci]

DCI 上下文的大多数示例都是作为命令模式实现的。但是，在使用依赖注入时，将依赖注入到构造函数中并将参数发送到执行方法中很有用。比较命令模式类：

使用依赖注入类：

最后一个似乎更好一些，但我从未见过它像这样实现，所以我很好奇是否有任何事情需要考虑。

有方法的角色包含实际的算法，但是上下文执行方法除了执行其中一种方法之外应该做什么？

看起来很简单，所以我认为 Context 应该负责例如数据库查找。这不会简化有条理的角色吗？

我即将设计一个由多个开发人员实施的软件。

该软件有许多复杂的用例，涉及来自 UI 的几个步骤和命令。我希望与 UI 和业务逻辑有一个明确的分离，因此，每个用例的不同状态不应由 UI 驱动/控制，而是在较低层中，使 UI 本质上是“愚蠢的”。

我考虑过混合 DCI 和状态模式来解决这个问题。

我想知道您对类似应用程序的体验，如果可能，请接受您的建议。

谢谢！

我正在研究 CreditCardPayment 上下文，并发现某些上下文方法并不需要所有角色。例如，该方法CreateSecurityHash可能需要所有角色，但VerifyHash只需要一个。不绑定所有角色可以吗？如果是这样，那么引入多个构造函数并只绑定需要的内容怎么样，如下所示：

虽然很难知道在执行此操作时允许调用哪些上下文方法。所以我想知道：

• 这还可以吗（如果可以，为什么？），或者
• 整个场景是否表明需要另一个上下文，或者
• 我是否应该始终保留上下文并提供角色所需的所有对象？

更新：我已经简化了我的问题；您可以通过查看我的编辑修订来查看完整的历史记录。感谢iain和bernardk让我走到这一步。

我想将载波功能加载到我的User < ActiveRecord::Base模型实例中。

执行：

结果是：

NoMethodError：未定义的方法new' for nil:NilClass from /Users/evan/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/carrierwave-0.6.2/lib/carrierwave/mount.rb:306:in 上传器'

我怀疑问题是mount_uploader在HasAnAvatareigenclass 上没有正确调用 in user，因此没有uploaders填充散列。

关于如何使它工作的任何想法？

这是针对此问题的示例 Rails 应用程序：https ://github.com/neezer/extend_with_avatar_example

默认的 Rails 4 项目生成器现在在控制器和模型下创建目录“关注”。我找到了一些关于如何使用路由问题的解释，但没有找到关于控制器或模型的解释。

我很确定这与社区当前的“DCI趋势”有关，并想尝试一下。

问题是，我应该如何使用此功能，是否有关于如何定义命名/类层次结构以使其工作的约定？如何在模型或控制器中包含关注点？

想象一下，您有一个处理用户账户之间资金转移的上下文。

汇款由 Web 应用程序触发，处理该操作的 Rails 控制器执行类似这样的操作

所以我的问题是，上下文可以引发异常吗？我应该在上下文中捕获角色异常并引发上下文异常吗？（上下文用户应该不知道正在使用哪些角色），有没有更好的解决方案？

谢谢

Thread.current这段代码有什么用？我正在查看在Rails 应用程序中使用 DCI 的示例。在 lib/context.rb 中，有这样的：

它用于 app/contexts 中的各种上下文，例如：

in_context在块中运行代码并在当前线程上设置键值对有什么好处？

我一直在尝试了解 DCI（数据上下文交互）（http://tidyjava.com/dci-architecture-visionary/）

在我看来，“角色”可以通过创建从基类继承并可以访问所有私有成员的派生类来模拟。这是一个合理的说法吗？

或者，这是否可以被视为过多的基础设施？我的意思是，DCI 似乎是将动作与类分开。这不是很好的 ol' C，你有对结构进行操作的函数吗？