The biggest concern I have with Doctrine 2 is that it requires developers to
explicitly define class members in their code. This is ok in many cases, but
consider the case of a CMS that allows users to define their own fields
through a GUI w/o coding. The way to accomplish this would be to store field
definitions in a database somewhere and load them up at runtime (cached of
course), and store the actual data in a private member array called $data.
For example Doctrine requires this:
class User {
private $username;
public function setUsername($username)
{
$this->username] = $username;
}
public function getUsername()
{
return $this->username;
}
}
where it would be much more flexible and powerful to allow just:
class User {
private $data;
public function setUsername($username)
{
$this->data['username'] = $username;
}
public function getUsername()
{
return $this->data['username'];
}
}
Doctrine already relies on getters/setters to 'hydrate' models...but
nonetheless uses reflection to ensure the member is defined. I submitted an
issue request on Doctrine's JIRA and was told that Doctrine 'relies heavily'
on that reflection and it would be very difficult achieve this. They said
that it 'might' be in a very future release. And that's just not an option
for sites that need dynamic fields.
I know I could rewrite the classes using Zend_CodeGenerator on the fly, but
that makes other things like implementing Iterator and ArrayAccess more
difficult.
Regardless, I think Zend is important enough to have it's own ORM. If it had
a performant and above all, easy to use, ORM, it could be THE killer
framework. Right now, Symfony is easily coupled with Doctrine (and Doctrine
requires parts of it) and seems to be gaining momentum. ORM would definitely
be one of the killer components of the ZF and significantly lower the
barrier to entry for new developers.
On Tue, Nov 16, 2010 at 1:46 PM, Benjamin Eberlei <[email protected]>wrote:
>
> Hello Nick,
>
> what would that issues/limitations be? For Doctrine 2 we haven't had any
> issue that we are not interested in.
>
> Doctrine 1.* however is in maintenance mode. It won't get any new features
> and only period bugfix releases. There is just no-one that volunteered to
> do a more intense maintenance on that code.
>
> greetings,
> Benjamin
>
> On Tue, 16 Nov 2010 09:58:23 -0700, Nick Daugherty
> <[email protected]> wrote:
> > I'm seeing a lot of talk about Doctrine 2 and ZF lately. Is the general
> > consensus that Doctrine is going to be used for object persistence,
> rather
> > than a new Zend component?
> >
> > Yes Doctrine is great, but it has some limitations, some of which are
> > non-trivial in complex applications and the maintainers have shown no
> > interest in working on these issues.
> >
> > I would much prefer a ZF component that has many of Doctrine's features,
> > but
> > uses ZF's db adapters and other components (caches, etc). I think not
> > having
> > ORM in ZF is a major hole and keeping if from being THE KILLER framework
> > for
> > the web. My vote is for a new ZF ORM that tightly couples with the rest
> of
> > the framework.
> >
> > On Sun, Nov 14, 2010 at 6:28 AM, David Muir
> > <[email protected] <davidkmuir%[email protected]><
> davidkmuir%[email protected] <davidkmuir%[email protected]>>
> >> wrote:
> >
> >>
> >>
> >> monk.e.boy wrote:
> >> >
> >> >
> >> > weierophinney wrote:
> >> >>
> >> >>
> >> >>> (APC http://php.net/manual/en/book.apc.php will help your speed
> >> issues)
> >> >>
> >> >> APC is one solution -- and that applies to ZF1 as well. However, the
> >> >> better solution is to profile the code and re-architect pain points
> to
> >> >> make them more performant. The autoloading/plugin loading milestone
> >> >> was
> >> >> highly focussed on this, and the outcome has been very rewarding --
> >> >> 7-20x speed increases!
> >> >>
> >> >>
> >> >
> >> > Agreed! The work you guys have done is amazing.
> >> >
> >> > But Doctrine2 is almost insisting [1] that you use
> >> > APC/Memcache/XcacheCache so it looks like a lot of us will be going
> >> > down
> >> > that route. Is this something you are going to recomend with ZF2? Is
> it
> >> > something you think about when writing/testing v2.0?
> >> >
> >> > [1] ref:
> >> >
> >>
>
> http://www.doctrine-project.org/projects/orm/2.0/docs/reference/configuration/en
> >> >
> >> > monk.e.boy
> >> >
> >>
> >>
> >> The cache they're talking about is metadata caching. ZF1 already
> >> recommends
> >> this for Zend_Db_Table's metadata[1].
> >>
> >> What Matthew was referring to was opcode caching [2], not data caching,
> >> although some opcode caches offer general purpose caching
> functionality,
> >> ie.
> >> APC and Xcache
> >>
> >> [1] ref:
> >>
> >>
>
> http://framework.zend.com/manual/en/zend.db.table.html#zend.db.table.metadata.caching
> >> [2] ref: http://en.wikipedia.org/wiki/List_of_PHP_accelerators
> >>
> >> Cheers,
> >> David
> >> --
> >> View this message in context:
> >>
>
> http://zend-framework-community.634137.n4.nabble.com/ZF-2-0-when-and-what-tp3031964p3041719.html
> >> Sent from the Zend Framework mailing list archive at Nabble.com.
> >>
>
