About ActiveRecord objects, Relations and how OOP relates to them

[Francesco Belladonna]

I have the feeling that there is something not great in the way we deal with ActiveRecord Relations and ActiveRecord objects, expecially after reading POODR.

Basically, when we write a class method on an activerecord object, we are adding methods to relations. This is great, allows for some nice things. What I'm concerned of is the fact that every model grows "twice" a standard class, usually because some relations are complex and require some methods.

So, I usually try to make my classes very small (~100 lines, no problem if it's bigger, but shouldn't be too much), but I can clearly see that there is something wrong when I have a relation that is supposed to have some methods and I put all those methods inside the class << self block.

Did anyone find a solution for this, or is concerned about it like me? I'm sure it could be improved. A CustomerRelation should be a different object than Customer.

[Avdi Grimm]

I think this is a symptom of the fact that AR mixes (among other things) both model responsibilities and repository/finder responsibilities in a single class. I too am curious how people have addressed this, if they have.

--
Avdi Grimm
http://avdi.org

--
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Wynne]

On 22 Dec 2014, at 14:02, Avdi Grimm <av...@avdi.org> wrote:

I think this is a symptom of the fact that AR mixes (among other things) both model responsibilities and repository/finder responsibilities in a single class. I too am curious how people have addressed this, if they have.

I addressed it by not using Rails anymore :trollface: :cheeky-grin:

cheers,

Matt

---

ma...@mattwynne.net

[Shane Mingins]

You could still use Rails and just not AR double( :trollface: :cheeky-grin:)

Sent from my iPhone

> On 23/12/2014, at 10:53, Matt Wynne <ma...@mattwynne.net> wrote:
>
> :trollface: :cheeky-grin:

[Francesco Belladonna]

I thought about it as long as I'll stick with Ruby, that's where my love is :P

But I can't change the existing stack of the software I'm working on, too big

--
You received this message because you are subscribed to a topic in the Google Groups "Objects on Rails" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/objects-on-rails/HR24Qq18jC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to objects-on-rai...@googlegroups.com.

[Marten Veldthuis]

If you're concerned about them, you could just move them to a Concern.

Seriously though, I've seen a couple "solutions" that try to use AR models like a repository and copying the data over to simpler objects after AR returns it. I haven't liked them so far. To do so seems like you're working really hard to push AR in directions it isn't designed to go.

Maybe we need something more complicated than Sequel (because who wants to write WHERE when you can write .where()), but returning dumb data structures instead of models.

- Marten

--

You received this message because you are subscribed to the Google Groups "Objects on Rails" group.

To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.

[Francesco Belladonna]

I don't feel like pushing, I mean, the entire ActiveRecord thing is built on the fact that class methods belongs to a relation, even SCOPES work in this way.
It just happens that we are writing the code for two classes into the same one (even if those are class methods).

Probably, if ActiveRecord was split between (suppose) Contact and ContactRelation (so ActiveRecord::Base and ActiveRecord::Relation) even when using it (not only internally), it may have been better.

--
You received this message because you are subscribed to a topic in the Google Groups "Objects on Rails" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/objects-on-rails/HR24Qq18jC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to objects-on-rai...@googlegroups.com.

[Andrew Premdas]

In the context of rails I think there are practical solutions based on using the controller part of rails to put a facade/wrapper around/in-front of your ActiveRecord objects. There are two sorts of facades you need, one for objects coming out of the model layer to the view, and one going in frome the views to the model layer.

Going from the model layer can be started quite neatly with something like Draper. The key here is that the methods you add to your models are generally added in the facade (layer), rather than directly in the model. This can include a range of things from QueryObjects to small methods to remove conditionals from views. This type of facade is all about extending the method signature of the 'model' objects in a context specific way, hence the ideas of presenters/decorators.

Going from the view to the model layer you ned a very different sort of facade. Here the emphasis is all about reducing the method signature you can communicate with. This sort of facade hides AR implementation and instead present a simple context sensitve api. Using this pattern you get many simple controllers that are tied to a particular method in the facade, rather than one complex controller dealing with a range of situations. You also get a more complex view/controller relationship, there is no reason that the same controller that renders a view should process the actions from that view

Since Rails 2 we've had the idea of REST, but we just don't seem to have got Resource/Representation based design. The idea that a resource/representation is not an AR model just doesn't seem to have stuck. Resource/Representations are context specific (driven by behaviour). AR models are data specific, and a convenient tool we can use to add persistence to our implementation. They are a long way apart, and its perfectly reasonable to put layers of code inbetween them to connect them.

Growing Rails Applications in Practice talks about having AR models that are just validations and callbacks. In addition to being a very interesting idea it demonstrates a key principle that the way to use AR and Rails in general is with great restraint. Yes you can add loads of class methods to your AR models, but you don't have to.

------------------------

Andrew Premdas

blog.andrew.premdas.org