Business Logic Layer Pattern on Rails? MVCL

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 开发者_JS百科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.

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.

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.

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.