Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is not your application

blog.firsthand.ca

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Rails is not your application

#11

Post by wildster »

ajdecon wrote: post #5

I'm not typically a Ruby/Rails programmer, but this seems to me like a different take on good advice I was given a while back: "Whenever possible, build libraries, not apps." If my code does anything at all which might be decoupled from this particular program or webapp, I try to break it out into a library, which I then call from the app I'm working on. This sometimes results in some extra work when working on that…

It's one thing pull elements into libraries it another thing to put the whole model layer into the lib directory,

Re: Rails is not your application

#12

Post by generalk »

joelmichael wrote: post #4

In Rails, the application belongs in app/, not lib/ or a gem. If this does not meet your admittedly obsessive design concerns then I suggest not using Rails.

You do understand that when the author says "your app" what is meant is "the domain or business logic that drives decisions."

Seriously, what's with the attitude? There's more than one way to architect software and Rails doesn't cover every single base. Pulling business logic out of your ActiveRecord models and into separate classes makes it easier to test and easier to manage code that interacts with more than one model.

Lighten up.

Re: Rails is not your application

#13

Post by jshen »

k33n wrote: post #9
generalk wrote: post #8

Earlier quoted context omitted.

> 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 me…

> 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 pl…

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.

Re: Rails is not your application

#14

Post by generalk »

casenelson wrote: post #10
k33n wrote: post #3

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 memb…

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…

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

Re: Rails is not your application

#15

Post by afex »

i go one step further, and put the domain layer behind a network interface (http or other) with a versioned API. IMO, trapping behavior inside a single application is just as bad as tying it to a framework. the domain layer needs to be available to the entire organization.

rails is just a tool to build a front-end app. i have many of those on my project. some rails, some sinatra. if they want to access shared behavior or data, they include the appropriate gem which knows how to access a particular API.

Re: Rails is not your application

#16

Post by devs1010 »

I think the bottom line with this is you shouldn't be using a framework as the entire architecture of your application. Frameworks usually are designed to do a few things very well, in the case of web frameworks, they provide the mechanisms needed to receive http requests and return responses elegantly along with rendering output from the server-side language into an HTML format. Beyond that, there is a much larger world of application architecture and design that goes beyond any "canned" framework. Web frameworks are great and very much fill a need but they aren't a panacea to make every project trivial.

Re: Rails is not your application

#17

Post by mattmcknight »

generalk wrote: post #8
k33n wrote: post #3

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 memb…

> 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 me…

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

Re: Rails is not your application

#18

Post by ldite »

I'm not particularly familiar with rails (or even web or client/server in general -- I'm more of an embedded/systems type) but this post gives me a strong feeling of the youth of today rediscovering the lessons of yesterday, to wit, properly abstracting the application from presentation.

Re: Rails is not your application

#19

Post by jacques_chester »

ldite wrote: post #18

I'm not particularly familiar with rails (or even web or client/server in general -- I'm more of an embedded/systems type) but this post gives me a strong feeling of the youth of today rediscovering the lessons of yesterday, to wit, properly abstracting the application from presentation.

Indeed. "Services" often sound suspiciously like well-dressed subroutines.

Re: Rails is not your application

#20

Post by minikomi »

k33n wrote: post #9
generalk wrote: post #8

Earlier quoted context omitted.

> 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 me…

> 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 pl…

I'll use this space to point people towards http://www.padrinorb.com/ Padrino. Seems apt!
Post reply on HN