4 ms·

Architecture Astronaut

bonif 12y ago
+1
ebiester 12y ago
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.
- gerry_shaw 12y ago
  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.
  - d4mi3n 12y ago
    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.
  - rmchugh 12y ago
    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.
  - Rapzid 12y ago
    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.
  - berkes 12y ago
    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.
- dominotw 12y ago
  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.
- rafekett 12y ago
  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.

bonif 12y ago

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.

gerry_shaw 12y ago
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.
- d4mi3n 12y ago
  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.
- rmchugh 12y ago
  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.
- Rapzid 12y ago
  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.
- berkes 12y ago
  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.
dominotw 12y ago
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.
rafekett 12y ago
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.