问题标签 [dci]

我首先通过这篇博文了解了数据、上下文和交互(DCI) 。对这个概念着迷，我努力将它构建到我的下一个 Rails 应用程序中。由于 DCI 与 MVC 协同工作，我认为同时使 API 成为 RESTful 不会太难。所以我制作了一个 RESTful 资源，并使用各种上下文对其进行扩展。我在 Rails 中实现上下文的方式是为扩展控制器操作的模块创建一个目录。所以我的样子是这样的：Report/app/contexts/reports_controller.rb

在application_controller.rb我设置上下文时before_filter：

请注意，除了控制器上下文之外，我还扩展current_user了 a 。Role

以下是它的工作原理：

1. 用户登录。
2. 用户的角色是RegisteredUser。
3. RegisteredUser的默认上下文是Search（定义在 中/app/roles/registered_user.rb）。
4. 在Search上下文中，用户只能查看已发布的报告。
5. 用户按下“创建新报告”按钮，上下文更改为Submission并存储在current_user的会话中。
6. 然后，用户继续通过多步骤表单提交报告。
7. 每次用户通过单步执行表单来保存报告时，/app/contexts/submission.rb上下文都会处理该操作。

还有其他几个上下文（评论、社论等）和角色（合著者、编辑等）。

到目前为止，这种方法在大多数情况下都运作良好。但是有一个缺陷：当用户打开多个浏览器窗口并更改其中一个窗口的上下文时，所有其他窗口都将处于错误的上下文中。如果用户处于多步骤表单的中间，然后在Search上下文中打开一个窗口，这可能是一个问题。当他切换回表单并点击“下一步”时，控制器将执行由Search上下文而不是Submission上下文定义的动作。

我可以想到两种可能的方法：

1. Report使用上下文名称命名资源。所以用户会访问诸如/search/reports和之类的 URL /submission/reports/1。这对我来说似乎不是 RESTful，我宁愿保持 URL 尽可能干净。
2. 将上下文名称放在隐藏字段中。这种方法需要开发者记住在站点的每个表单中都放置隐藏字段，并且它不适用于 GET 请求。

有没有其他方法可以解决这个问题，或者更好的整体实现？

我知道这个项目，但它对我们的需求来说太有限了。

有没有办法使用 Scala 的类型系统来简洁地指定完整对象图的上下文相关子图？

DCI 认为您通常拥有一个相当复杂的对象图，但在任何一个用例中，您通常只想使用子图。你有 a Foo，它有 aBar和 a Bat，但是当你在用例 1 中时，你只关心Bar和 在用例 2 中时，只关心Bat.

例如，假设您有这个结构，并且 Role1 用例需要Foo->Bar->Baz->Bin，Role2 用例需要Foo->Bat->Baz->Buz：

很容易看出如何通过使用特征来限制单个类中的访问：

但是您必须为与用例相关的每个对象重复此模式。（例如，您需要 a BazInRole1to accessbin和 a BazInRole2to access biz）

我的问题是是否有某种方法可以避免编写所有这些容易出错、名称空间拥挤的特征。例如，我可以想象这样的代码（不能编译）：

似乎 Scala 的类型系统足以表达这样的事情，但我无法弄清楚。

最近与一位同事就在 Rails 应用程序中设计和编码模型的不同方法进行的辩论让我了解了 Rails 上下文中的 DCI。

但是，即使在查看了这个示例应用程序之后，我似乎也无法完全理解整个概念。

目前，在编写 Rails 应用程序时，我倾向于或多或少地“按部就班” 。

所以我想问一些事情——

• 什么是 DCI，当与 MVC 一起实施时，它相对于普通的旧 MVC（以及 Rails 中的香草 ActiveRecord）有什么优势？
• 它如何在 Rails 中实现（或者换句话说，所有模块都有什么用）？

编辑

我想在 RoR 的上下文中进一步扩展我的问题 - 是否建议在 Rails 中的模型和控制器之间进行另一层抽象？它在不同规模的应用程序中有多广泛？

我正在为我的最新项目使用 AngularJS。在文档和教程中，所有模型数据都放入控制器范围内。我知道必须有控制器可用，因此必须在相应的视图中可用。

但是我认为该模型实际上不应该在那里实施。例如，它可能很复杂并且具有私有属性。此外，人们可能希望在另一个上下文/应用程序中重用它。将所有内容都放入控制器完全破坏了 MVC 模式。

这同样适用于任何模型的行为。如果我要使用DCI 架构并将行为与数据模型分开，我将不得不引入额外的对象来保存行为。这将通过引入角色和上下文来完成。

DCI ==数据协作交互_ _

当然，模型数据和行为可以用普通的 javascript 对象或任何“类”模式来实现。但是 AngularJS 的方法是什么？使用服务？

所以归结为这个问题：

遵循 AngularJS 最佳实践，您如何实现与控制器分离的模型？

在跟随The Right Way to Code DCI in Ruby之后，我一直在玩 DCI 。我发现我一直希望我的角色为我的数据对象添加属性。

例如，如果我有一个用户对象。

用户可以扮演顾客的角色。

为了完成这项工作，我需要添加一个购物车方法。购物车真的属于用户对象吗？感觉角色应该根据需要将购物车添加到数据对象中。

我正在 Java 中寻找一些示例，以便更好地理解什么是 DCI 以及应该如何使用它。

我在这里的 C++ 中找到了一些很棒的 DCI 示例http://fulloo.info/Examples/C++Examples/Account1/

如果您不熟悉 DCI 架构，请在此处阅读http://www.artima.com/articles/dci_vision.html或在此处观看一些介绍http://www.tele-task.de/archive/video/flash/ 16130/最后一个链接更多地是关于 OO 的弱点。

额外的问题：DCI 真的是下一个范式转变吗？

我最近看到了 Trygve Reenskaug 关于 DCI 的以下演示： https ://vimeo.com/43536416 这让我大吃一惊。嗯，在代码中看到软件不同组件之间的交互是一个很有吸引力的想法。

我试图在 javascript 中找到 DCI 的示例，但没有成功。然后我开始怀疑。DCI模式不是与事件编程模式相反吗？

事件编程在 javascript 中很流行，我猜是因为它允许解耦，并且因为经典继承概念不是 js 原生的。我想我了解事件编程的好处，但我也注意到当需要跟踪事件消息时，调试可能会非常困难。

说这两个概念是对立的是否正确？还是我弄错了？是否有一些我错过的 js 中 DCI 的示例实现？为了挖掘这个概念，我应该看什么？

我正在关注 DCI 来构建新 Rails 应用程序的行为，但我对在哪里放置验证有一些疑问。

传统上，如果您要使用 ActiveRecord 模型管理数据，则在继承自 AR 的特定类中定义验证，并且它们似乎适合作为数据层的一部分。

但是，在我看来，只有在特定角色下才会发生某些验证是有意义的，并且只有当对象在该上下文中时才应该检查它们，而在所有其他情况下都被忽略。这基本上意味着这些验证应该在特定角色中定义，并且当对象在有意义的上下文中使用时，应该使用这些角色模块进行扩展。

你认为在角色中保留这些验证是个好主意吗？如果是这样，你如何声明它们而不污染同一类的其他实例而不是对象？如果我想使用 ActiveRecord 验证，它们是在类级别声明的，所以我不能将它们单独附加到对象，被迫在角色模块上使用“验证”实例方法的重新声明（附加错误直接到对象的错误数组），或一些类似的技术。

我正在考虑如何以及何时可以在 Web 应用程序中使用 DCI 上下文。我正在考虑这个高级用例：

1. 用户输入城市、到达、离开、房间类型并点击“搜索”。
2. 系统显示酒店列表
3. 用户单击酒店徽标以阅读其详细信息
4. 系统显示酒店详情
5. 用户点击“立即预订”
6. 系统显示付款表格
7. 用户输入客户详细信息、账单信息并点击“提交”。
8. 系统验证计费信息并显示预订确认。

这是非常高级的，肯定需要分解。第一步（1-2、3-4、5-6）感觉像是可以通过一些搜索和 REST 架构处理的简单资源请求。所以我的第一个问题是，在这些情况下是否需要 DCI 上下文，纯 MVC 还不够吗？当然，“酒店”数据实体可以发挥作用，但您认为它可行吗，尤其是如果它是唯一的参与者？

最后一步是我看到 DCI 可能非常有用的地方，因为现在需要以程序方式进行工作。（创建客户、向酒店添加预订、发送确认邮件……）

您对此有何看法？我在正确的轨道上吗？

如果我使用 ASP.NET MVC 框架，实例化一个 Context 并且那里出现问题，是否可以抛出异常并让 Controller 处理它？

然后对于嵌套上下文，外部上下文是否可以捕获内部上下文抛出的异常？我在想是因为上下文无法相互了解，但另一方面，错误就是错误……对吗？