Rails 上的业务逻辑层模式？ MVCL
这是一个广泛的问题，我不喜欢简短/愚蠢的回答，例如：“哦，这是模范工作，这个任务是迟缓的（时期）”
问题我在哪里工作人们花了 2 年多的时间创建了一个系统，用于以最简单但尽可能广泛的方式管理超过需求的制造流程，涉及销售、购买、组装，该系统通过 Ruby On Rails 进行编码。
该应用程序已经更改了很多次，结果是回调（有些被调用多次）、200 多个模型和胖控制器上一团糟：完全糟糕。
问题是，是否有一个 gem 或模式旨在处理 Rails 大型应用程序逻辑？逻辑应该能够与模型充分对话（其唯一关心的是数据格式处理和验证）
我期望是降低各种控制器的复杂性，并且很难跟踪到具有责任的文件中的回调处理业务操作逻辑。在某些情况下，需要等待响应，而在其他情况下，只需验证输入就足够了，并且会发生 bg 过程。
即：
-->出售一些产品（需要等待操作完成）
1.设置一个可以获取产品输入的View
2. 控制器获取员工输入的产品清单并调用逻辑
Logic::ExecuteWithResponse('sell', 'products', :prods => @product_list_with_qtt, :when => @date, :employee => current_user() )
该逻辑将处理采购订单、组装订单、机器调度、仓库预订等。
请记住，SalesOrder 上的回调是不够的，因为它取决于调用它的位置（没有相应的字段），取决于用户的类别，以及模型不可见的其他内容，或者在某些情况下它会模型需要很长时间才能处理。
That is a broad question, and I appreciate no short/dumb asnwers like: "Oh that is the model job, this quest is retarded (period)"
PROBLEM Where I work at people created a system over 2 years for managing the manufacture process over demand in the most simplified still broad as possible, involving selling, buying, assemble, The system is coded over Ruby On Rails.
The app has been changed lots of times and the result is a mess on callbacks (some are called several times), 200+ models, and fat controllers: Total bad.
The QUESTION is, if there is a gem, or pattern designed to handle Rails large app logic? The logic whould be able to fully talk to models (whose only concern would be data format handling and validation)
What I EXPECT is to reduce complexity from various controllers, and hard to track callbacks into files with the responsibility to handle a business operation logic. In some cases there is the need to wait for a response, in others, only validation of the input is enough and a bg process would take place.
ie:
--> Sell some products (need to wait the operation to finish)
1. Set a View able to get the products input
2. Controller gets the product list inputed by employee and call the logic
Logic::ExecuteWithResponse('sell', 'products', :prods => @product_list_with_qtt, :when => @date, :employee => current_user() )
This Logic would handle buying order, assemble order, machine schedule, warehouse reservation, and others.
Have in mind that a callback on SalesOrder is not enough, since it depends on where it is called (no field for that), depends on the class of the user, among other stuff not visible for the model, or in some cases it would take long for the model to process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
业务对象和逻辑的固有复杂性需要为团队处理、理解和内化（或至少记录良好）。那不会消失。我的建议是获取遍布“胖”控制器的所有逻辑，并将它们移至域对象、应用程序服务（服务层）或简单的事务脚本中（请参阅 Martin Fowler 的“企业应用程序架构模式”）。
理想情况下，嵌入在回调迷宫中的所有业务逻辑都可以重构为上述组件以促进理解。这消除了控制器上随着时间的推移而建立的所有附带复杂性。但即使在摆脱所有这些之后，我怀疑问题领域仍将存在一定程度的固有复杂性。
The inherent complexity of the business object and logic will need to be tackled with, understood, and internalized (or at least documented well) for the team. That will not go away. The recommendation I have is to grab all the logic peppered throughout the "fat" controllers and move them into either the domain objects, application services (service layer), or simply transaction scripts (see Martin Fowler's "Patterns of Enterprise Application Architecture").
Ideally all the business logic embedded in the labyrinth of callbacks can be refactored into components described above to promote understanding. This gets rid of all the incidental complexity built up over time on the controllers. But even after getting rid of all that, I suspect a certain level of inherent complexity will remain in the problem domain.
服务层的思想是以良好的方式合并与某些模型无关的高级逻辑。如果您开发集成了多种服务并且拥有大量数据源的企业级系统，您应该更好地关注 Eric Evans 的领域驱动设计 (DDD)。当然，Fowler 的《企业模式》书在这种情况下也很适合。
另请参阅DataMapper（2，第一个与ActiveRecord类似）。它对于此类系统有更好的设计方法，并且比 Rails 中的 ActiveRecord 具有更少的限制（在概念层面上）。
老实说，这是因为 Ruby 人员的动态本质，他们长期以来一直在解决 ActiveRecord 的概念问题并尝试满足企业需求，恕我直言。
The idea of Service Layer is to incorporate high level logic which is not associated with certain model in a good way. If you develop enterprise like system with multiple services integrated and have number of data sources you should better look to Domain-Driven Design (DDD) by Eric Evans. Surely, Fowler's Enterprise patterns book is good in this case too.
Also look at DataMapper(2, the first one was similar to ActiveRecord). It has better design approach for such type of systems and have less limitation (on conceptual level) than ActiveRecord in Rails.
Truly say, that's because of dynamic nature of Ruby people so long tackling conceptual problems of ActiveRecord and try to fit it enterprise needs, IMHO.
有些人已经在服务层和回调方面做了一些工作，Pat Maddox（尤其是回调）是其中之一，Jay Fields（他早期围绕 Rails Presenter 模式所做的工作后来被类似服务层的模式所取代）是另一个。我必须承认我喜欢添加额外层的想法。对我来说，业务逻辑不属于模型，模型应该在复杂的项目中解耦。我也喜欢在回调之上添加一个额外层的想法，对我来说，随着数量的增加，回调变得过于复杂，
这远非成熟的 DDD，目前我不知道 DDD 在 Rails 中如何工作，但是，我确信它可以，而且我确信现在有人正在研究它。对于我的项目来说，目前实施起来有点大材小用，但是，我会考虑添加一个服务层。
Some people have done some work out there on service layers and callbacks Pat Maddox (especially callbacks) is one, Jay Fields (his very early works around the rails presenter pattern later to be replaced with a service layer like pattern) is another. I must admit I like the idea of adding a extra layer. To me, business logic just doesn't belong in models and models should be decoupled in complex projects. I also like the idea of an extra layer over callbacks, for me callbacks become too complex as there numbers increase
This is far from full blown DDD and at the moment I don't know how DDD would work in Rails, however ,I am sure it could and I am sure someone is working on it out there right now. For my projects, at the moment, it would be a bit of a overkill to implement, however, I would consider adding a service layer.