Object Relational Mapping

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

record "collections" is an issue I'm trying to address in Querify (was: kQuery) - I like the way jQuery deals with objects and collections, it makes sense to try and apply the same concepts to ORM.

As people have stated before: ORM is not a magic-SQL-bullet. However, if it speeds up 95% of your development, I would consider it to be a success.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

wow, 95% that is a pretty high expectation ;), i would consider 50% a success as to factor in gotchas that any design will inheritantly have. I guess it also depends on the proficiency of the current user. I would also consider maintanance a criteria, e.g. how would someone else react to the code if you decide to leave the project that uses some sort of ORM (assuming that the new person have not use that ORM before, as this will be most likely in the PHP areana).
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I have never found O/RM to speed up development -- in fact it usually slows things down. What it does provide is a major flex point between the OOP design and the database schema. Especially with a changing database schema. That is the problem that O/RM was intended to solve.

Kieran, I think that (and perhaps others in this thread) are taking about Query Building rather than O/RM. It is confusing because O/RM systems often resort to implementing Query Builders -- but that is usually to make their job easier, not yours.
(#10850)
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

@arborint: I'm totally thinking about query building to a large extent - it's difficult to separate it from ORM in my opinion.

@wei: 95% is an awfully high estimate, but it helps keep me motivated ;-) In actuality I only meant the development time associated with data retrieval, manipulation and storage.. not the entire development process!
Begby
Forum Regular
Posts: 575
Joined: Wed Dec 13, 2006 10:28 am

Post by Begby »

I spent a lot of time in the past trying to build ORM classes and they all sucked. The problem was that they were never flexible enough for complex queries. Recently I have begun working with much larger projects primarily coding abstraction layers to the backend for other teammates, and this has changed my perspective.

Instead of trying to build a set of very flexible ORM tools that will work with everything, I now code from pretty much scratch a ORM class for each entity using a set of interfaces/patterns.

This has changed my perspective from "how will this code translate into SQL joins and what not and be flexible" to "How can I code this class so it makes the most sense when I or the other developers are using it". I also need to keep this flexible enough so at some point I could easily replace the backend with a different database or even something more extreme like moving to a complete web services backend.

What this has resulted in is a set of three classes for each entity (keeping in mind that an entity might span 10 tables).

Collection class for working with more than object
Manager class for reading and writing from the database
Entity class which is a representation of the object containing data, validation code, business logic, but no actual SQL.

I also have a parameters class which is analogous to the propel criteria class. I had to add this in as I was creating way to many manager methods. I might need to make this entity specific but we'll see.


I figure out how I am going to create the entity class by typing in how it should work in code while ignoring the database structure completely. For instance our backorder database structure is really complicated, but I don't want any of that complexity in code. Using an ORM mapper like propel would make it even more confusing. I just have a releaseBackOrders() method in the manager class that has the required SQL all laid out in an easy to follow fashion.

When I add an order, then add products to an order, the API does not mirror the database structure. Instead I set it up so that its make sense and is easy to use. The manager class sorts it out and creates the SQL.
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

thanks for that Begby - I've always been worried that I'm trying to build a swiss army hammer. I'll keep developing this for now, just out of curiosity, but I can completely see your point.
marcoski
Forum Newbie
Posts: 1
Joined: Tue Aug 28, 2007 6:05 am
Location: Italy

Post by marcoski »

Hi all,

Is an Object Relational Mapping library the case where apply any concurrency rules?

In detail, following viewtopic.php?t=48499 implementation design, is the DataAccess object affected of any lack of concurrency or DBRMS subsystem deals those problems?

Thanks all
Post Reply