Hacker News Reader

Comment by germanogmn1 | Hacker News Reader

Architecture Astronaut

Say that again after you have to learn a rails app with 1500 line models built "the rails way." Controller -> model breaks down when you reach a certain size.

Or worse, giant controllers and models with no clear distinction.

You can go a long way with using simple Ruby objects to break up logic and separate out logic from models. If developers are writing 1500 line models and the lead developer isn't doing anything about it a adding new abstract concepts isn't going to help.

the author argues based on his experience refactoring legacy Rails apps that these problems are so common that they must stem in some way from the framework. I'm not sure how true this is, but my experience is that Rails doesn't give you a lot of help in defining where this extra logic should go. There are a lot of blogs and the like with differing suggestions about how to structure your Rails app, suggesting that this is a real problem and that there is no real consensus on how to fix them. Personally I'm happy to see a framework which builds on the best features of Rails while also trying to offer some solutions for applications that have outgrown the simple MVC structure.

I really cant agree with this enough.

A very common example of model bloat I see is authorization logic, and libraries like Pundit do an excellent job providing a simple framework for extracting such logic into their own ruby classes.

In a way a lot of parts in Trailblazer are just that: "simple Ruby objects to break up logic and separate out logic". Not just from models but in the views, controllers and other places too.

Lots of Rails devs go through a process like the following:

* I want to introduce a Subscription, but that is not something stored in the database, rather it creates an Order, Invoice, Account and assigns products to them. Let me create a simple PORO for that.

* Now, where to stick that? Models? For now, that will do.

* I want to introduce a Trial, which is rougly similar to the Subscription just with different parameters.

* I want to introduce an Upgrade, wich can turn a Trial into a Subscription.

... and so on.

Quickly turning your "simple Ruby objects" into an even larger mess then the mess they try to solve. So you'll be adding abastractions, giving them names and common places in your app. And there: you've just built a part of a framework like Trailblazer.

Yeah, and I don't think anemic models are the way to go. That's swinging back the other way too hard. Rails could do with promoting a service/app layer if anything new were to be introduced. A healthy dose of DDD concepts.

I thought the original promise of rails was that you could use traditional OO concepts to combat complexity.

Rails doesn't tell you to stuff all your logic into models.

I think the issue is monorails (monolithic rails apps). If you have a single domain object you're representing that's that complex, you'd done a poor issue of modeling your domain. It doesn't matter if you write the logic in the model or controller, at that point you're just pushing code around -- you need better abstractions.

Reply on news.ycombinator.com