ZF2 issue report (2013-08-22) - result for Zend\Db

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 issue report (2013-08-22) - result for Zend\Db

Kyle Spraggs
Using Doctrine ORM is like any other third-party library. You have to ask yourself if the increase in development speed makes up for the reduction in performance? For most everyone that answer is a resounding, *yes*. 

Very few people work on an application where the performance of an ORM will even come into play. If you're a lead developer of one of those applications then you should be qualified enough to make your own decision.

In short, if you don't know whether or not an ORM will impact your application then you're probably safe to use one.

Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Tue, Aug 27, 2013 at 10:33 AM, Axel <[hidden email]> wrote:
Well this should be no philosophy discussion. Calm down a bit, ok?

I know there is a great and widely used ORM: Doctrine. But the comment from Martin Keckis seems to show that there is a need for a different kind of ORM based on Zend\Db (what ever that may look like).

If this is not the case, then fine, just wanted to figure it out. I don't want to see an ORM in the the ZF core as well more an optional module or component. And definitely no "Doctrine killer"...


Am <a href="tel:27.08.2013%2010" value="+12708201310" target="_blank">27.08.2013 10:12, schrieb Axel:
Hi Everybody,

Am 22.08.2013 21:03, schrieb Martin Keckeis:

When going through the list and looking what requests are in, I feel like that most people want an ORM like Doctrine, if they use Zend\Db.


Interesting, I'm currently implementing a simple ORM solution based on the zf2 TableGateway classes.
This is not yet complete and will still receive major design changes.

Here's what I've got so far: https://github.com/tux-rampage/rampage-php/tree/master/library/rampage/simpleorm

Basic theory:
- TableGateways are repositories
- An EntityManager aggregates them and a UnitOfWork instance
- Classes can annotate repositories with @Repository the UnitOfWork/EntityManager will use this to find the repository for an object.
- Repositories may aggregate other TableGatways to handle refereneces (this completely up to the developer)
- Data from objects is automatically extracted via a hydrator instance
- Additional TableGateway features provide automatic configuration of the hydrator instance by using the metadata, populating the last insert id, etc...
- Utilize database transactions if possible when flushing the UnitOfWork.

So you could do something like that:
$serviceManager->get('EntityManager')->persist($object)->flush();


Any thoughts? Worth to port it to a standalone ZF component? Suggestions are welcome.


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 issue report (2013-08-22) - result for Zend\Db

ThaDafinser
In reply to this post by Axel


Am 27.08.2013 17:33 schrieb "Axel" <[hidden email]>:
>
> Well this should be no philosophy discussion. Calm down a bit, ok?
>
> I know there is a great and widely used ORM: Doctrine. But the comment from Martin Keckis seems to show that there is a need for a different kind of ORM based on Zend\Db (what ever that may look like).
>

There is no real need for that. The problem is that people start using Zend/Db and then after some time, they check that some things could be done different...like in an ORM.

So an issue is opened for that.

Like i said in the first post: its just a feeling based on my...and nothing concrete.

> If this is not the case, then fine, just wanted to figure it out. I don't want to see an ORM in the the ZF core as well more an optional module or component. And definitely no "Doctrine killer"...
>
>
> Am 27.08.2013 10:12, schrieb Axel:
>>
>> Hi Everybody,
>>
>> Am 22.08.2013 21:03, schrieb Martin Keckeis:
>>
>>> When going through the list and looking what requests are in, I feel like that most people want an ORM like Doctrine, if they use Zend\Db.
>>>
>>
>> Interesting, I'm currently implementing a simple ORM solution based on the zf2 TableGateway classes.
>> This is not yet complete and will still receive major design changes.
>>
>> Here's what I've got so far: https://github.com/tux-rampage/rampage-php/tree/master/library/rampage/simpleorm
>>
>> Basic theory:
>> - TableGateways are repositories
>> - An EntityManager aggregates them and a UnitOfWork instance
>> - Classes can annotate repositories with @Repository the UnitOfWork/EntityManager will use this to find the repository for an object.
>> - Repositories may aggregate other TableGatways to handle refereneces (this completely up to the developer)
>> - Data from objects is automatically extracted via a hydrator instance
>> - Additional TableGateway features provide automatic configuration of the hydrator instance by using the metadata, populating the last insert id, etc...
>> - Utilize database transactions if possible when flushing the UnitOfWork.
>>
>> So you could do something like that:
>> $serviceManager->get('EntityManager')->persist($object)->flush();
>>
>>
>> Any thoughts? Worth to port it to a standalone ZF component? Suggestions are welcome.
>
>

Del
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 issue report (2013-08-22) - result for Zend\Db

Del
In reply to this post by ThaDafinser

There have been a lot of good points put forwards on this discussion and
I think everyone's been good at keeping a level head for the most part.

I think that the arguments below carry a lot of weight.  For one or two
projects back in the ZF1 days I used the ZF1 LDAP interface but
eventually discarded it in favour of the PEAR Net_LDAP interface which
was a PHP implementation of perl's Net::LDAP.

Net::LDAP is the gold standard in OO interfaces to an LDAP directory and
I think that the ZF1 developers actually did themselves and their users
a bit of a disservice by implementing something that wasn't as good,
wasn't as useable and wasn't as flexible, when there was a perfectly
good, better, free (LGPL) and pluggable LDAP interface in PHP already
out there.  Basically, work got taken away from other projects to work
on something that was a poor shadow of Net::LDAP.

I think this is just another example of "gain resources to create other
cool stuff".  Find a need and fill it.  If there is no need, there
should be no filling it.  I don't think we have a need for another good
ORM when there is a perfectly good useable one out there already.

If Doctrine ORM was in fact too heavy for small projects then fine but
as others have already pointed out it's actually still small enough and
lean enough to be used in a project with a single database table, while
remaining large and flexible enough to take on the largest projects.  I
don't currently see a need for a replacement.

If you want something fast and light then sure use mysql_query() but you
know you're going to lose the flexibility that an ORM has, and using a
lightweight ORM isn't going to cut it in terms of flexibility either.

I'm currently working on one project in Laravel where they have used the
Laravel ORM (Eloquent) and I really wish I had Doctrine back again.  If
only because we have hit so many bugs in Eloquent and had to fix those
ourselves because of the small size of the Laravel development team --
those bugs aren't a factor in an ORM like Doctrine.  This incidentally
is why I would still caution against developing a lightweight ORM for
ZF2 -- because a lot of time will be spent fixing bugs in it, time which
could be offloaded onto another project's resources.

Del

> I hope no one takes the next paragraph personally, i also used Zend\Db
> in ZF1 a lot and it worked great, but:
> I personally would completely remove Zend\Db...and so gain ressources to
> create other cool stuff.
>
> Even if someone don't want to use a complete ORM, there are also many
> DBAL around which work.
>
> Best regards
> Martin

123