ActiveRecord - dynamic way

[kyberfabrikken]

Except that in Ruby, class methods are NOT static calls, they are dynamic, so they're inherited by subclasses, and they can be mixed in from other modules. The coupling is in fact quite loose.

I don't know ruby, so I may be missing a point here, but is a class an object in ruby ? If not, how can you pass the class to a subroutine ?

In any case, it's possible to have your cake and eat it, too. Ergo:

You lost me completely there ?

Edit:


Ah - I get it. You're suggesting to have a separate finder, but to let the activerecord serve as a decorator over it, so that user can decide which approach to use ?
That's a pretty good compromise actually.

[michel]

In any case, it's possible to have your cake and eat it, too. Ergo:

class ActiveRecord {
   
       function find() {
           $args = func_get_args();
   
           $finder = new Finder();
   
           return call_user_func_array(array($finder, 'find'), $args);
   
       }
   
   } 

This is how I've been using find*() methods for the past 8 months. A Finder instance is responsible for all SELECT queries. It's assigned as a private instance variable. A class named ActiveRecord_Finder is instantiated by default. This class can be extended for special cases (named after the ActiveRecord extension it belongs to, [ActiveRecordExtension]_Finder). Works fine for me. I see no reason to use static calls.

[Luke Redpath]

I don't know ruby, so I may be missing a point here, but is a class an object in ruby ?

Yes. Everything is an object in Ruby.

[matid]

Generic mappers is NOT the way to go imho, because it requires you to put all your special finder-methods in one big class.

I'd like to go for a mapper that you have to extend to use, but you don't have to write any methods in it until you want some extra functionality.

Anyway, I really appreciate that you all shared your point of view on this matter. I'm still pledging through PoEAA to find the best solution though.

[topsmith]

Right now, we do:

class News extends ActiveRecord {

  public static function find() {
    $args= func_get_args();
    return ActiveRecord::build(new QueryBuilder(__CLASS__, $args));
  }

}

so, basically we force the user to write a dummy find method.
The QueryBuilder object knows how to build sql select statements based on $args and with the help of an SQLCommand object (somehow inspired by the last year talks on fluid interfaces).

On every informations that we gather, the build method will know how to execute an sql select, how to bind (replace ? with values) prepared statements and how to return instances of the News class with data loaded.

Code:
ActiveRecord
QueryBuilder
SQLCommand

p

[33degrees]

I don't know ruby, so I may be missing a point here, but is a class an object in ruby ? If not, how can you pass the class to a subroutine ?

Sorry for not being clear, but yes, as with everything else in ruby, classes are objects, and can be passed as a method parameter. There's no such thing as a static call in Ruby, all calls are late bound.

Ah - I get it. You're suggesting to have a separate finder, but to let the activerecord serve as a decorator over it, so that user can decide which approach to use ?
That's a pretty good compromise actually.

A more appropriate term would be a Facade. Fine-grained objects are good for flexibility and maintainability, but can make for overly complex apis, a common problem in class libraries for which the facade pattern is a common solution.

[kyberfabrikken]

Yes. Everything is an object in Ruby.

In that case, clearly the choice of language has a lot to say about which design is better. With PHP, I wouldn't want to use classmethods since they are static.

[lastcraft]

Hi...

Fewer objects is definitely a concern of mine; domain models can get pretty complicated, and doubling the number of objects by implementing finder classes for each one seems like an inefficient approach to me.

You don't usually need to. Most objects are collection members to other objects. You only need finders for the big top level domain classes and there aren't usually that many.

yours, Marcus