Rails core,
I was wondering if Rails 5 has a discussed (or proposed) roadmap? A growing chorus of developers are seeking ways to separate domain logic from persistence logic at the model level. I was wondering from a bird’s-eye perspective if the framework plans to adopt patterns to make that easier (and more encouraged) to implement in the future?
I tried to do a little googling for Rails 5 docs but I was unable to find solid stuff.
-Jason
We don’t have any roadmap yet besides the drop of support o Ruby 1.9.
About your specific question I believe it is unlikely we provide something besides what we already provide with Active Model.
Rails comes with a default structure that serves well a ton of apps, but does not mandate that you use that structure as is, which is a common misconception/starting point in talks, posts, etc.
Those are the defaults, but of course projects can add their service objects, form objects, decorators, and whatever they want. Tailor-made for their needs or their personal preferences, which are legit.
What it is not going to happen in any foreseeable future is that the default structure changes. The only change in that direction has been to add a convention for code organization via modules (concerns).
I'd like to add I've personally done dozens of (gasp) well-written apps using the default layers in the last decade, do not believe every generalization or theoretical argumentation you read out there. Think with your editor.
Got it, thanks.
I agree that as a framework there is no architectural mandate, and that the idea that there is one is a (too) common misconception. It is unfortunate that people coming to the framework do not have the perspective to know that (and in turn create a lot of unsustainable code).
The main architectural issue I would take with Rails in its entirety (and pitfall I’ve seen on dozens of badly written apps myself) is the encouragement of over-use of callbacks and, of course, the all-too-common domain logic where it shouldn’t be. I’m sure everyone knows on some level what I’m talking about, and yes, I agree this is not fundamentally Rails’ fault but instead the fault of the developers who use it.
I wonder if there’s a way we can provide better documentation or training to alternatives design approaches — well within the paradigm of what Rails is currently capable of (as you pointed out).
-Jason
I agree that as a framework there is no architectural mandate, and that the
idea that there is one is a (too) common misconception. It is unfortunate that people coming to the framework do not have the perspective to know that (and in turn create a lot of unsustainable code).
The main architectural issue I would take with Rails in its entirety (and pitfall I’ve seen on dozens of badly written apps myself) is the encouragement of over-use of callbacks and, of course, the all-too-common domain logic where it shouldn’t be. I’m sure everyone knows on some level what I’m talking about, and yes, I agree this is not fundamentally Rails’ fault but instead the fault of the developers who use it.
I wonder if there’s a way we can provide better documentation or training to alternatives design approaches — well within the paradigm of what Rails is currently capable of (as you pointed out).
I don't know.
For example, some people say business logic in AR models violates SRP! ZOMG! And look at the ancestor chain! Look at user.methods.size, that... must break some principle or another!
Those people would write some kind of documentation.
Other people look at the code and say: it's fine and simple to understand, models encapsulate, some models are not ARs, controllers coordinate. Find a balance. Extract as needed. Do after/before comparisons. Works like a charm for many applications. If it does not work for your particular application, grow a design tailored for it.
In my view, It depends so much on the application and personal design preferences that you cannot generalize. I don't think "if your ARs grow too big insert an entire new layer of POROs and extract everything there" is an advice you can document like that in the Rails documentation, to pick an example. And the Rails documentation shouldn't have a catalogue of patterns that we generally cannot recommend by heart.
If I could suggest something, I would say: DOUBLE PERFORMACE
I don’t want to go into specifics because most of what I’m working on is still high level ideas. I doubt that we’ll see a separated persistence and business logic layer land in Rails any time soon (though internally we’re actually becoming very close to that). However, we are continuing to break things into smaller pieces which may eventually be made public and can be re-used by other libraries like Virtus or ROM.
One of the biggest places for this is having clearer lines between what happens at the AR class level, vs the DB table level, and how the two communicate. I’m hoping to reduce the number of places that take a class object which inherits from AR::Base as part of their arguments, in favor of objects which represent the concept they need, which again should help reusability without having to inspect hundreds of methods across dozens of modules to figure out what the expected interface actually is.
I don’t have anything specific other than rough ideas of where things need to happen to get there, and this is all just ideas that may or may not actually happen. My concern is more on improving maintainability of the internals, hooks for gem makers, and fixing bugs, rather than user facing API. Even if everything does happen, it might not result in anything that you use in your rails apps.
The Rails team gladly awaits your benchmarks and Pull Requests to help make that happen, Bráulio 
While we are on the subject of potential changes, I asked in a previous thread about what’s gonna happen to controller tests (functional tests in previous parlance) and got no response. I am asking for two reasons: 1. It was one of the proposed GSOC projects, so it is to be expected that someone picked it up, and 2. I think it’s a mistake to deprecate them (the wording was to unify them with integration tests, but from what I read it seems that they’ll essentially be deprecated) and I plan to write more on the subject if what I suspect is true. But perhaps suffice it to say that the renaming to controller tests alone has already eased most of the confusion out there.
BTW, something that is in the radar is replacing accepts_nested_attributes_for with something else, maybe form objects... it is just being explored (and could end up in nothing).
I hope I’ll be able to contribute more to rails Kasper, thank you!
Hello,
I’ve been giving a lot of thought to building a gem which puts more validation into the controllers and routing and removes it elsewhere. My conclusion was that I didn’t need to build a gem, Rails in fact already has everything needed to accomplish this, however - I just need to change the default pattern it provides. I’d like to share my thoughts and receive yours -
route validations, strong_parameters, and ActiveModel are sharing responsibility but are split across framework.
What if the instead of defining a single set of validation rules with a single class inheriting from AR per table, the default was to define several valid persistable-object states per table with a series of ActiveModel Prototypes.
What if setters, getters and validations were mixed in by virtue of these AM Prototype classes (I think default setters/getters are AR defined atm?). Further, the Prototype would guard persistence, like a state machine, since ‘create’, ‘save’, ‘update/patch’, ‘destroy’ would not be defined/mixed-into every Prototype, only ones appropriate for the action.
Really, all this already exists - for instance, routing allows you to define regex’s to match incoming parameters – but how many people are using this? (that’s a real question, I have no idea). Then we have controller level validation with strong_parameters. Then we have model level validation. Why not move all this into some form of Prototype which defines what keys are open, required, what they can, should, should not look like (type checking), etc?
This approach also has one cool side benefit - nicer introspection which can aid front end generators / frameworks.
I’m posting here cause I haven’t thought this through fully and when I try to write out a DSL for this I start going off course – but to my delight a few have touched upon these things in this thread, if I’m reading your thoughts correctly.
DCI is the solution to all architectural problems.
вівторок, 25 листопада 2014 р. 08:57:07 UTC-8 користувач Xavier Noria написав:
I’d love to see more use for Rails Engine and make it a default way of developing application.
#go Rails Engines
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks