I believe this is where I will make a fool of myself, but I will give it
a shot anyway.
1. Yes, we scratch built the system in house.
2. Your correct, if we make a change to the schema of the database we
have to represent that change in data model. If we remove something
from the database and don't reflect that change in the data model the
system complains. However, this seems like a very small price to pay.
The data model is the representation of all the objects in the system.
If I want to know what is in an object, I go to the data model and check
its relationships and attributes. The methods for each object are not
in data model, they are defined in the
3. Our system is not zero configuration. If you want access to
something in the db you have to put it in the data model. We also have
to configure all our db brokers.
In our system all we have to do is load the parent object:
$Hans = new Person();
$Hans->SetId($PersonID);
$Hans->Populate();
I now have access to all the objects that $Hans knows about. If I want
to update Hans:
$Hans->Name = 'Sue';
$Hans->Update();
If the Person object knows about the address object and the address
object knows about the location object (which is all defined in the data
model) I access them by:
$Lattude = $Hans->HomeAddress->Location->Latitude;
It should be noted that we have ways of defining a name for a
relationship in an object. So, we might call the address relationship
for the person object HomeAddress and only select home addresses when we
call $Hans->HomeAddress. If we called $Hans->Address, if we defined
it, we might get back a set of all of Hans' addresses. In which case we
have an iterator to go over them. $Hans->Address[0], $Hans->Address[1],
ect.
The ORM fetches the relations and data automatically. If we eager
loaded it, it will already be in the object, if we didn't eager load it,
the system makes the sql calls to find it just in time. We define on a
per relationship level if we are going to eager load or not. As you can
imagine, eager loading is expensive.
I am truly not the expert here, I am not even sure how it all works on
the inside. I leave it to those smarter then me to work it out. What I
can tell you is that it currently works for us.
The blog post by Ted Neward is a very interesting read. Now I am going
to pay attention to where we fall victim to his assertions.
Hans
http://www.cyberxdesigns.com
Is this a system you've built in-house?
I've certainly seen places where ORM was as much of a problem as it
was a solution. On the other hand, I've done more than my share of
maintainance on applications where sql code is distributed throughout
the application, and (worse) applications where people developed a
database layer which encapsulated bad practices and bad assumptions
about the problem domain.
One basic trouble with ORM is that it violates the principle of
"don't repeat yourself;" you have to maintain a database schema ~and~
an object hiearchy. Change one, and you have to change the other.
Another problem is that there is a semantic mismatch between objects
and sql -- there are three ways to represent inheritance relations in
sql, and all three are unsatisfactory in some way.
I've been working lately with a minimalist "active record" that
introspects the database, and lets you write something like
$table=$db->{my_table}
$row=$table->fetch($id);
$row->{count_value}=77;
$row->update();
it saves a lot of fumbling with 'addslashes' or '?' parameters,
thus eliminating a common kind of repetitive coding. It doesn't try
to map database 'rows' to anything else, but it can still automate
certain aspects, such as timestamping changes to rows, and keeping
an archive of who changed what when. I've been trying to develop
something that does 20% of the work and eliminates 80% of the pain of
writing "plain old" applications with lots of SQL. So far the system
is zero-configuration, although I'm sure I'll add features to it
someday that require some configuration -- for instance, I do see an
easy way to implement a certain kind of inheritance.
ORM systems do get interesting, however, in architectures that
really take advantage of the objects. For instance, if you can
design your objects so that aspects cut across them, you can build
really powerful systems quick.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
--
Hans C. Kaspersetz
Cyber X Designs
Office: 201-558-7929
Mobile: 201-681-4156
[EMAIL PROTECTED]
http://www.cyberxdesigns.com
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
