Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team members. There are tons of people who are Rails experts, and are very familiar with its paradigms and features. People like this can very quickly get up to speed with just about any Rails project. A large team can also communicate and work much more efficiently if they are all using the same code structure/helpers/etc. If you're a one man show, it might work just fine for you to build specialized gems for all of your "application" (though the line you've drawn between application and framework seems pretty vague) though there is going to be a fundamental lack of structure to your entire project. It'll make sense to you for a little while until it gets so big that even you don't understand it. It's going to be difficult to perceive test coverage, and in practice, all those little gems are going to vary pretty wildly in structure.
You'd be better off just using Sinatra and including ActiveRecord, and whatever other Rails libraries you want to use.
> Sounds like you shouldn't be using Rails if this is your philosophy.
> You'd be better off just using Sinatra and including
> ActiveRecord, and whatever other Rails libraries you want
> to use.
What seriously? Something doesn't fit inside Rails' neat cutouts so obviously the solution is to get rid of Rails? This smacks of "if you don't like Rails, go somewhere else." Just because you're using a framework doesn't mean you can't do anything outside of it, ever!
I mean, take Rails. It gives you a LOT of convenient stuff that you wouldn't want to throw away wholesale, but if you have a Customer model and a Card model, where do you put the checkout code? It could go in either place.
A great solution is to put it into lib/checkout.rb and write a custom Checkout class that manages how Customers and Carts interact. Not only does this make it super-easy to test outside of ActiveRecord, but it consolidates the code in one common place, and you haven't tossed out Rails for no reason.
Exactly. Makes perfect sense to me. If you're not going to lean on the framework, why even use the entire stack? You can pick and choose the parts of it you like, and want to use under the context of something like Sinatra which is meant for that sort of thing.
> but if you have a Customer model and a Card model, where do you put the checkout code? It could go in either place.
You can put it in either place. I'm not sure I understand why just because there's some flexibility on where you can put method X you should just work completely outside of the framework.
Edit: But this is a different point than the original debate though. I think the blog author goes way too far in avoiding using the framework.
You can pick and choose the parts of rails as well. I have a rails 3.1 app that doesn't use active_record at all, but it does use active model and encapsulates the service layer in model objects.
"A great solution is to put it into lib/checkout.rb and write a custom Checkout class that manages how Customers and Carts interact."
That is significantly different than implementing a service layer, which "defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation." In your typical ServiceLayer style app, most of the calls are just direct passthroughs to the domain model.
Frankly, the controller layer is a sufficient service layer for many complex applications, as it handles different clients and request types. There is often foolishness in putting too much of that logic in a single controller method, but it is wrong to suggest that adding the overhead of the service layer pattern in place of referencing the domain model from the controller fixes this (putting it in lib certainly makes a bit more sense).
The example given in the article is a bit of a horror show. It's probably not a service layer. I am sure a bit is left out, but it's going to convoluted lengths to avoid putting anything in the domain model. Dynamically extending individual instances of employee to add a pay_date method? Creating a new instance of the service on each request- when it could be done with static methods?
Sadly, it doesn't make sense to model your whole domain twice. Let's see what the employee service used to list, add, update, and remove employees is like. Any real system is going to end up with a domain model object to represent a payroll, which is where this logic could go.
The root problem is Uncle Bob just doesn't like the ActiveRecord pattern- in which case just use a different ORM.
If you have customer and credit card model, I'd implement the checkout process inside Order and OrderItem model classes. It would probably use an AASM state machine to represent the progress through the purchase etc.
Working against Rails, or any framework, is definitely going to cause pain. On the other hand, Rails is not perfect and I, like the OP, have been noticing a number of voices lately worrying about building large Rails apps. Which is awesome, because either Rails will adapt or something new will come along to fill the need.
Sinatra + cherry picking rails lib might work great if you've built a few apps like that, but it would nice to package this approach in a framework which guides people down this road.
Personally, I feel that Rails could evolve to the point where the approved path involves using some adapter (like a service layer) to talk to ActiveRecord. I've written about how Java accomplishes this in comparison to ActiveRecord: http://casestatement.tumblr.com/post/11514731433/javas-jpa-f...
> Working against Rails, or any framework, is definitely
> going to cause pain.
There is a huge difference between working "against" a framework and working outside, or better yet alongside of it.
You want a Service layer that abstracts logic from database commands? You can absolutely do that while still taking advantage of the entirety of Rails. Your controllers and views are instantiating your objects and not ActiveRecord objects, but that's not a crime.
Rails is not your application framework. It is not well-suited to being your application framework. We have exactly this problem in the Python world, where people lean on Django for everything, and insist on making everything interoperate with Django's view of the way the world should be.
It doesn't work. Factor out as much as you can and make as much of your code into units as possible. You want to be able to test your code, run it and inspect it, and have it overall be very non-magical.
You'd be better off just using Sinatra and including ActiveRecord, and whatever other Rails libraries you want to use.