I agree that the optimal solution would be a base ORM solution that all others
can build off of and use. Just like PDO, it doesn't have to be an end all
solution. Just implement the major features that all ORM projects have.
The mailing list is great to pick at the brains that have been building such
solutions for years. Coming to a solution for a common API would be better in C
as a PHP extension. It would also be easy to check for the existence of the
extension to use it.
Jacob Santos
Hello!
This paper seems to be interesting, but I don't have the time to read it
now. If only there were such nice documentations when I started this!
On the performace point, I can't say anything well-grounded since I have
no benchmark results. I'll do some when I have a little more time, then
we'll see.
The other thing you mentioned ... the bundled ORM tool. I think it would
be good to have a "standard sollution" over the current diversity.
An analogy came to my mind ... session handling and object persistence.
Of course session handling is a much simpler task, I think they share
some common points. Like both can be implemented in a number of ways.
For session handling now there's a standard implementation that works
good for allmost all cases.
I don't say, that a similar thing can be achieved for ORM, nor do I say
that there should be one ORM implementation that everyone must use.
However I think that currently the ORM palette is too diverged (like if
everyone would use their own session implementation). There would be
good, if there were some "standard" thing, that fit's most people's
needs.
The bad thing is AFAIK that ORM is interpreted in many ways by PHP
developers, so there can't be a one-fits-all solution. For example there
are the structured programmer, who don't want to here about objects and
classes, but want a nicer interface to access their data in their
database. Taking these people into account when building an ORM is very
important if we want to keep PHP an easy to learn language.
Than there are the people who do everything object oriented, want some
of their objects to be persistent, and (for some reason) want them to be
stored in a relational database.
And there a lot of people in between, who would use an ORM solution
mixed with a lot of SQL.
I only mentioned three use cases, but in reality, I'm sure that the
image is much more complex.
However I believe that a "common divisor" could be found, something
common in all these cases, that can be made into some form of standard.
This shouldn't have many features, but should be extensible.
I think if the different more developer-friendly solutions were built on
"common divisor", it would result in better high level features, a nicer
learning curve (don't have to start from 0 when you need to learn a new
ORM implementation) and so on and so on.
What I'm really talking about, in the OO aspect, is a base class that
provides only some very basic (but very important) ORM features. It
should be small, quick and extensible. It should also have a really
good, intuitive interface.
What you think?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
