3 ms·

> 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

> 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.

k33n 15y ago
> if you don't like Rails, go somewhere else 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.
- jshen 15y ago
  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.
- minikomi 15y ago
  I'll use this space to point people towards http://www.padrinorb.com/ http://www.padrinorb.com/ Padrino. Seems apt!
mattmcknight 15y ago
"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.
Vitaly 15y ago
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.

k33n 15y ago

> if you don't like Rails, go somewhere else 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.

jshen 15y ago
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.
minikomi 15y ago
I'll use this space to point people towards http://www.padrinorb.com/ http://www.padrinorb.com/ Padrino. Seems apt!

mattmcknight 15y ago

"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.

Vitaly 15y ago

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.