Rails 上的业务逻辑层模式？ MVCL答案

【问题标题】：Business Logic Layer Pattern on Rails? MVCLRails 上的业务逻辑层模式？ MVCL
【发布时间】：2011-01-26 23:54:55
【问题描述】：

这是一个宽泛的问题，我不欣赏这样的简短/愚蠢的回答：“哦，那是模范工作，这个任务被推迟了（句号）”

问题在我工作的地方，人们创建了一个系统超过 2 年，用于以最简化但尽可能广泛的方式管理制造过程，包括销售、购买、组装，系统被编码Ruby On Rails。

该应用已更改了很多次，结果导致回调（有些被多次调用）、200 多个模型和胖控制器一团糟：完全糟糕。

问题是，是否有设计用于处理 Rails 大型应用程序逻辑的 gem 或模式？能够与模型完全对话的逻辑（其唯一关心的是数据格式处理和验证）

我期望是减少各种控制器的复杂性，并且很难将回调跟踪到负责处理业务操作逻辑的文件中。在某些情况下需要等待响应，在其他情况下，只需验证输入就足够了，并且会发生一个 bg 过程。

即：
--> 出售一些产品（需要等待操作完成）
1.设置一个可以获取产品输入的视图
2.Controller获取员工输入的产品列表并调用逻辑

Logic::ExecuteWithResponse('sell', 'products', :prods => @product_list_with_qtt, :when => @date, :employee => current_user()  )

此逻辑将处理采购订单、组装订单、机器计划、仓库预订等。
请记住，对 SalesOrder 的回调是不够的，因为它取决于调用它的位置（没有字段），取决于用户的类，以及模型不可见的其他内容，或者在某些情况下它会模型需要很长时间才能处理。

【问题讨论】：

标签： ruby-on-rails design-patterns business-logic

【解决方案1】：

团队需要处理、理解和内部化（或至少记录良好）业务对象和逻辑的固有复杂性。那不会消失。我的建议是抓取遍布“胖”控制器的所有逻辑，并将它们移动到域对象、应用程序服务（服务层）或简单的事务脚本中（参见 Martin Fowler 的“企业应用程序架构模式”）。

理想情况下，嵌入在迷宫般的回调中的所有业务逻辑都可以重构为上述组件以促进理解。这消除了控制器上随时间累积的所有附带复杂性。但即使在摆脱所有这些之后，我怀疑一定程度的内在复杂性仍将存在于问题域中。

【讨论】：

很好的答案。我最终得出了类似的结论；复杂的业务复杂性不会简单地消失。我们已经制作了一些结构来处理它，而不是混乱的保存回调。我会看看你的参考

【解决方案2】：

服务层的思想是把与特定模型无关的高级逻辑以一种好的方式结合起来。如果您开发集成了多种服务并拥有大量数据源的企业类系统，您最好看看 Eric Evans 的领域驱动设计 (DDD)。当然，Fowler 的企业模式书在这种情况下也很不错。

另外看看DataMapper(2，第一个类似于ActiveRecord)。与 Rails 中的 ActiveRecord 相比，它对此类系统具有更好的设计方法，并且（在概念层面上）限制更少。

说实话，这是因为 Ruby 人的动态特性，长期以来一直在解决 ActiveRecord 的概念问题并尝试满足企业需求，恕我直言。

【讨论】：

【解决方案3】：

有些人在服务层和回调方面做了一些工作，Pat Maddox（尤其是回调）是其中之一，Jay Fields（他早期的作品围绕 Rails Presenter 模式，后来被类似服务层的模式取代）是另一个.我必须承认我喜欢添加额外图层的想法。对我来说，业务逻辑不属于模型，模型应该在复杂的项目中解耦。我也喜欢在回调之上增加一层的想法，对我来说，随着数量的增加，回调变得过于复杂

这远非成熟的 DDD，目前我不知道 DDD 将如何在 Rails 中工作，但是，我确信它可以并且我确信现在有人正在研究它。目前，对于我的项目，实施起来有点矫枉过正，但是，我会考虑添加一个服务层。

【讨论】：