> > One such area is unit testing; it's far easier to test a plain old PHP
object than it is to test something that has couplings to the database -- which is what happens when your entities extend from a base class. This. Also because Doctrine is established, has many users and wide acceptance, the backing of a company, and a compatible license. We currently use it where I work, and while I have many issues with it, 2.0 will probably fix most of them. (I probably won't get a chance to use it, however; we're switching to Java EE for technical and staffing reasons.) -Matt On Wed, Nov 25, 2009 at 7:09 AM, Matthew Weier O'Phinney <matt...@zend.com>wrote: > -- Arié Bénichou <arie.benic...@gmail.com> wrote > (on Wednesday, 25 November 2009, 03:21 AM -0800): > > Reading the > > http://www.doctrine-project.org/blog/php-5-3-and-doctrine-2-0-teaser > > doctrine 2.0 teaser , I noticed that Doctrine planned to eliminate the > > need for an entity to extend from a base class. Althought, it sounds > > like writing an entity class is a little bit easier, since it can be > > any plain old php object, the reasons were not given. Then you said, a > > such base class is the root of all evils... Could you please, explain > > the difficulties you faced with entities having to extend a base > > class? > > One such area is unit testing; it's far easier to test a plain old PHP > object than it is to test something that has couplings to the database > -- which is what happens when your entities extend from a base class. > ORM's are supposed to remove such couplings, not introduce them. > > > > beberlei wrote: > > > > > > > > > Hello, > > > > > > Its not a failure to recognize that a proposal generates lots of > > > "duplicate > > > code", which is currently better solved in other projects. This also > > > has nothing to do with Zend, since the component was approved > > > under the premise that its community contributed. An ORM is a huge > > > undertaking and it creates lots of code that has to be maintained > > > and I as a community member decided that its probably not doable. > > > > > > Xyster ORM maybe existing for some time, however i haven't seen it in > > > use. Additionally although they claim not be ActiveRecord you have > > > to extend a certain base class for your entities to work with it. > > > This is the root of all evil in ORMs and the reason why enterprise > > > ORMs don't require it. > > > > > > The lead developer of Doctrine is indeed paid by SensioLabs, however > > > the Source Code is under the LGPL, which is a perfectly compatible > > > license with New BSD and doesn't restrict the use of the code. > > > There is also no effort whatsoever by SensioLabs to control Doctrine. > > > > > > Looking at it the other way, Doctrine is already several years old, > > > plus it benefits from lots of experience of the PEAR MDB2 component > > > aswell as others (eZ Components, ZF). The code basis is pretty robust > > > and there are people working on its perfection full time, which makes > > > it a pretty good choice for Enterprises. > > > > > > Going for Integration with Doctrine in my opinion is one step further > > > to professionaling php as an enterprise language. The different PHP > > > communities where cooking their own soups for the last 10 years. > Although > > > I like competition very much, one should also make rational decisions > > > when it is better not to reinvent the wheel. > > > > > > greetings, > > > Benjamin > > > > > > On Wed, 25 Nov 2009 00:51:38 -0800 (PST), Arié Bénichou > > > <arie.benic...@gmail.com> wrote: > > >> I don't understand why you did not use http://xyster.libreworks.net/ > > >> Xyster > > >> ORM > > >> It makes use of the Data Mapper Pattern and comes with a Unit of Work. > > >> Doctrine is shifting to this approach for the version 2.0, but it's > still > > >> an > > >> alpha release. > > >> It's a pity for you to have failed this way, because, Doctrine is > > >> associated > > >> to SensioLabs, the french agency who developps the Symfony Framework. > > > > > > > > > > -- > > View this message in context: > http://n4.nabble.com/Discontinuing-Zend-Entity-in-favour-of-Doctrine-integration-tp648011p787474.html > > Sent from the Zend Framework mailing list archive at Nabble.com. > > > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ >
