OR/M vendors tries to helping object developers to close the gap between the relational world and the object world.And they call this "object modelling approach" OR/M.
Using "custom business entities" in enterprise programming with OR/M might seem the best thing after "sliced bread" but it isn't.
For my part I have written my Mappers and used commercial OR/M tools.
They mostly provide the same thing.
__Read the table from the database.
___Put that into a some HELPER thing.(DAO,DAL,ORM)
____Put that into your custom business object
_____Read from your business object.(if u can :) )
I see NO REASON for this "Unnecessary Pull and Push".
"object modelling approach" makes NO sense.As to access a group of data,u have to create a custom collection where it is the WORST thing u can do in the business software development in terms of performance.(Arrays are evil).Such as 12 million ORDERS,can have 55 million ORDER_DETAILS and 5 million CUSTOMERS and no LAZYLOADING can help u.Object models use RAM and CPU resources which are really important in terms of performance.if u have more complicated object graph it will be slower.Some might say lets take the performance parameter out and think without it,those people see a "butterfly effect" on their project when they realize that they got to rewrite the application all over again.
So I am really hard on OO but I must admit that Object oriented modelling is a nice theory.(...an idealism that does not work in practice).
if u really go into object domain modelling.U will end up with all these things which are really not neccessary...
U have to deal with
A.identity Maps(read objects only once)
B.UnitOfWork(Transaction mechanism for your objects)
C.Topological Sort(To have right insert ,update orders)
D.Mappers(OR/M buy or build it...)
E.Repositories(common place to retreive your collections,if u can...)
F.Specification patterns / Query objects(filtering mechanism in objects POEAA)
G.Metadata Techniques.(some cool SQL reuse that makes the system slow,through code generation or reflection)
H.Design Patterns like FACADE to put everything under the rug...
Do u think is it worth it?
Also at the end of the day,u will face the fact that u need performance.(as the users say so it is Google time!,they just don't wanna wait,time is more valuable than money...)
Carefully looking at your UI code behind,u can easily find out that every user interface in your application has different aspects of data.And there is no ONE most important aspect.(Like u can't love your mum more than your dad...)
Object Models are not build to have many aspects of data as when designing them OO people don't think in a tabular way,they do think in a object way which is slow as their logic is eating RAM and CPU resources which are expensive.They are trying to reinvent the RDBMS idea at runtime.So every VIEW must be differently aligned for your business application user interfaces for performance.
people should also know what they are getting into OR/M world.
The Failure of OO developers is that they are tend to be see OO as a GOLDEN HAMMER.But the business software development has many aspects that,it is not wise to build an "OO Domain Model" where the world is consisted of objects.if u think about it tables are also everywhere in business enviroment.Table is an abstact logic to organize big amounts of business data.Like the simpliest example is;when u go to a train station , u never see OO chart of trains,the thing u see is a table with coloumns and rows telling u where to go and when to go.
I don't mean do not use OO, we should all use OO for some UI staff, but it is just no GOLDEN HAMMER that can solve every problem.Nibernate,toplink are nothing more than a tool replacing the old idea of OO.
So why do I write all these staff , to discourge OO people?
OfCourse not!Projects like hibernate are a really nice attempts to try to close the gap between the RDBMS and objects.But the practice and the theory doesn't have to match in daily life of a programmer.
People should invest time,money and energy in pratical ideas , not in OR/M idealism where there is no logical end.
PS: Myth: OR/M vendors might claim if u don't do OO , u will end up with a non adaptable code,spagetti code.
:=) Adaptability is in your head,not in your code...