21–30 of 33 posts
Rails is opinionated and forces a literal sense of MVC pattern, its dogmatic, thus the fat controller or fat model phenomena
I've found that a pretty simple technique along the lines of what's shared in the article makes complex Rails apps much more maintainable. Most of this applies to any MVC style app/framework. I follow these rules of thumb: 1. Controllers should only handle converting HTTP to ruby calls. That includes logic that is specific to the request flow, like parsing params or authenticating cookies, but nothing else. 2. Models…
I'm just starting out my Rails journey so I haven't encountered those issues yet.
I've found that a pretty simple technique along the lines of what's shared in the article makes complex Rails apps much more maintainable. Most of this applies to any MVC style app/framework. I follow these rules of thumb: 1. Controllers should only handle converting HTTP to ruby calls. That includes logic that is specific to the request flow, like parsing params or authenticating cookies, but nothing else. 2. Models…
Really interesting comment, thanks for sharing your experience. Can you expand on why Rails helper methods are bad? I'm just starting out my Rails journey so I haven't encountered those issues yet.
Why no helpers:
1. The scoping is weird and encourages bad patterns.
- You have access to the instance variables from whatever controller action happened to call the particular helper, but you can’t see that when writing the helper or in the view, so it’s very opaque. God forbid you actually USE the instance variables and you’ve now got these weird fragments of tightly coupled code between your controller and your template that quickly become hard to reason about.
- It’s better if you require that all helper methods be strictly functional, but in that case it’s still unintuitive because your methods are mixed into every view. This can lead to surprising name collisions and all kinds of other weirdness.
2. They’re not easy to test due to the issues above.
3. They’re weird to include elsewhere - for example if you want to reference in a model.
3. Most important: the principal value of common utility functions is to have the sort of “general purpose operations” defined in exactly one place, well tested, and then utilized everywhere else.
For all of these reasons you’re better off defining modules and using ‘module_function’ to make the methods directly accessible. Then you can just call the methods like ‘Utils.foo_bar()’ wherever you need them.
Sharing business logic between models/controllers/views often leads to a mess. There's a reason to just write business logic code at only ONE place, the controller. You'll thank yourselves years later when you revisited your code. Just one place to look for.
But placing logic in the controllers means you need to get a rails controller to test your business logic. This may seem fine in a small application, but as an app grows it becomes a headache to need to tie all your business rules to your framework. “Rails is not your application”
Earlier quoted context omitted.
But placing logic in the controllers means you need to get a rails controller to test your business logic. This may seem fine in a small application, but as an app grows it becomes a headache to need to tie all your business rules to your framework. “Rails is not your application”
If "Rails it not your application", why use Rails then ?
Earlier quoted context omitted.
Really interesting comment, thanks for sharing your experience. Can you expand on why Rails helper methods are bad? I'm just starting out my Rails journey so I haven't encountered those issues yet.
Welcome to Rails world! It’s a fun place to work :) Why no helpers: 1. The scoping is weird and encourages bad patterns. - You have access to the instance variables from whatever controller action happened to call the particular helper, but you can’t see that when writing the helper or in the view, so it’s very opaque. God forbid you actually USE the instance variables and you’ve now got these weird fragments of tigh…
You do not need anything other than the MVC pattern.
I would love to see the claimants of these needed abstractions post their code so I could refactor and show you how you're wrong.
If you make good use of your base controllers you can reduce controller code to next to nothing.
If you avoid Rails abstractions such as scopes use callbacks sparingly and focus on writing raw SQL instead of using Arel's query builder your models are easy to manage.
Been doing Rails development for 6+ years. The most maintainable codebases I've worked on had some kind of service layer between the controller and the model. We used the "interactor" gem to create individual units of business logic that we could reuse and piece together into larger "flows". Business logic stayed in the interactors, persistence logic in the models. This lead to skinny controllers, skinny models and m…
Once I actually started building stuff and writing tests I had my aha-moment. By putting most of my logic in a separate 'context' module, I could both use and test all that without having to do all the bootstrapping that was necessary to run the web-framework controller logic.
While this might seem obvious to some, for me it felt like a proper level-up as a developer, as I suddenly realized how the same principle could be applied in other contexts.
I've found that a pretty simple technique along the lines of what's shared in the article makes complex Rails apps much more maintainable. Most of this applies to any MVC style app/framework. I follow these rules of thumb: 1. Controllers should only handle converting HTTP to ruby calls. That includes logic that is specific to the request flow, like parsing params or authenticating cookies, but nothing else. 2. Models…
I rather like how Phoenix makes a clear separation between views and templates. The templates have no logic, but the views can have quite a bit of it as long as it is directly linked to the templates (presentational).
I've been using Rails since version 0.8.6 and have apps as old as 8 years I'm still maintaining. I've had teams as large as 20 on a single rails codebase. You do not need anything other than the MVC pattern. I would love to see the claimants of these needed abstractions post their code so I could refactor and show you how you're wrong. If you make good use of your base controllers you can reduce controller code to ne…