Thank you, fantastic info! I know it comes down to requirements, and those reqs govern the technology that would be selected.
That said I guess Im looking for advice. The project I am considering would be a SaaS solution, where the data layer will need to be highly optimized. The agnostic angle, is only important as far as not committing to a platform from a cost / architecture prospective. It will never be used as an open source project that would be deployed In different environments or DBs. Second priority would be having a standardized approach so hiring developers and getting them up to speed would be more efficient. While in the short term, being the only developer, I can gain some advantages as well. Quite honestly, doctrines performance issues concern me, but from generally what I find online is that doctrine is the most functional ORM. For this heavy DB usage (not so much triggers/procs) SaaS solution. You would still recommend orm, because of the advantages of the domain model? Thanks, your experience is very helpful! Cheers, Chad Sollis 801.792.7651 Please pardon any typos, this message was sent from my non-flash playing, closed platform, lazy iPhone. On Aug 16, 2010, at 2:21 PM, Alvaro Carrasco <[email protected]> wrote: > Hi Chad, > > See below: > > On Sun, Aug 15, 2010 at 2:42 PM, Chad Sollis <[email protected]> wrote: >> hey all, >> >> Matt's post a few days ago has me thinking, as I have looked at various ORM >> projects for PHP. It seems like the few always referenced are Doctrine, >> Propel, and Redbean, (and I'm sure matt's NORM will be there soon ;). >> >> However, i know there is a time and place for various technologies, as I >> have begun to dive into learning Doctrine, it seems intensely over >> complicated, and has significant performance problems (from a handful of >> websites I've found). >> >> Would someone (or many of you) help me understand where the benefits are in >> the added development time and learning, that cant be obtained by decent DB >> abstraction. >> >> I get the DB agnostic angle... looking for additional prospectives and >> insights... >> >> Many Thanks. >> >> ~Chad > > I tend to agree with Lonnie and a lot of his points. For me the main > reason for using an ORM is not the abstraction part which I can get > that with any decent data layer. The most important thing for me is > that having an ORM helps to create a domain model and to move to more > of an OOP way of solving problems. > > As an example, you can more easily write code like this: > > foreach ($client->getProcessors() as $proc) { > $proc->checkUser( $newMessage->getUser() ); > } > > The point of that contrived example is that when you have objects for > each of your entities in a domain, you can create relationships and > methods on those classes that better convey the *intent* of what you > are doing. That's a benefit of *domain model*, which is easier to > achieve when you have an ORM. You also tend to end up with methods > that are useful in other places and that are easier to unit test. > > When (and only if) you run into performance problems and *only after > you've identified where the problem is using a profiler*, you can > easily replace the contents of methods to be more efficient (maybe raw > sql if necessary). That way you're not doing misguided premature > optimization that is costly in readability and often done in the wrong > place. > > http://martinfowler.com/eaaCatalog/domainModel.html > > By the way I also created an ORM (i guess is a right-of-passage of sorts): > http://www.outlet-orm.org/ > > Alvaro _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
