own ORM: database records in case of JOIN?

We are doing our own framework with ORM capability. The database tables are classes now, but how about records? Lets imagine two tables:

Users
ID,USERNAME

Emails
USER_ID,ADDRESS

so, a record object will have getID(), getUSERNAME() methods, etc but if the two tables are JOIN-ed, it cant have two types right? Since there开发者_C百科 is no multiple inheritance. And what about field collision?

---

DBIx::Class handles this by having a Class for each table, and joins are represented by a method that gets an object matching the other table..

$myAddress = $myUser->emails->address;

---

I think every class should represent a record and a whole table should be an array (or some other collection) of objects. Take a look at http://www.doctrine-project.org/ to get some ideas.

And for JOIN, you should have some mechanism for defining aliases. That way, you can deal with field collision.

And for getters and setters, you can use __call, __get and __set. See http://php.net/manual/en/language.oop5.overloading.php for more info.

---

I'm providing some insight based on the Model/ORM implementation of this PHP UI Framework . Here are some suggestions from me:

• Don't decide blindly to map functions into fields. Why not use get('field') and set('field'). There is no downside (apart from lack of IDEs hinting), but you can avoid code generation or catch-all which usually is slower.
• When joining you wouldn't necessarily want multiple objects. In my ORM a single Model can work with joined tables. This introduces transparency and when you call $model->set('address') it might be associated with joined table. Im still using sub-instance of a dynamic query for sub-selects but for joins there is no need.
• I've see a lot of power of inheritance and ability to re-shape parent models in parent model. Each table can have multiple models depending on your business uses.
• Models and ORM should be separated but should play together very closely. I've also managed to make everything play well with generic views and generic controllers, which is a great time-saver.

Hopefully this would help find your own way or to decide on not implementing your own ORM. It's not an easy task.