Why will OR/M fail ?


General J2EE: Why will OR/M fail ?

  1. Why will OR/M fail ? (4 messages)

    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...

    Threaded Messages (4)

  2. Why will OR/M fail ?[ Go to top ]

    Nice article!!! But I agree partially with the author. OR/M tools can be real beneficial only if your database is nicely designed and normalized. At least I get JSTL friendly objects to work with and do not have to write any JDBC code with try-catch-finally.

    Trying to use OR/M with poorly designed database is nightmare and should be avoided. Tools like iBatis still work great with them...

  3. Why will OR/M fail ?[ Go to top ]

    You point out some valid issues.

    Most OR/M tools seem to ignore the fact that a large portion of use cases applies to sets and the interesctions of sets and not to individual objects.

    Very few designers pay enough attention to the associations and only concentrate on the objects.

    I can't remember coming across a tool that supports an associated class. UML defines an associated class and it fits naturally in many models but somehow seems to dissappear in the implementation of the models into multiple associations and a class.

    If OR/M tools supported a pattern that treats a set-of-classes as a first-class citizen we will find much more efficient implementations.

    I have noticed that Hibernate 3 query language supports update and delete operations and not just select. This allows the manipulation of the underlying data without loading/pulling objects into memory.

    The mistake we make is to try and treat an OR/M like an object-database.

    To blame object modeling is also not the answer. I believe object modeling is a sound method for managing and reducing the complexity of a problem. Believing that object modeling is somehow far superior is also a big mistake.

    We should use our tools in the way intended. This means we need to understand the intention of the designer and ignore the salesman.
  4. Why will OR/M fail ?[ Go to top ]

    Unless you are living under a rock..ORM is succeeding..
    A common design pattern is to create value objects for the database EJB(entity beans) attempted to do it..but Hibernate,JDO,etc succeeded...
    All ORM tools tries implement valueobejct code so u don’t have too.. you still need a DAO layer... To say it will fail is to say the design pattern for data value objects is not needed when working with databases… Hibernate implementation clearly says in the document that you can’t do everything by simply modeling the database..so it implemented a powerful query language called HQL… sort of what entity beans did..

    I don’t agree with the article can encourage him to pick up design pattern book, and seriously research ORM tools.
  5. True for some projects![ Go to top ]

    OO modelling is not useful for many projects of small size. However, once you come accross big project in which technical issues are easy compared with domain rules, you will find a comprehensive domain model your best aid - otherwise you will be overwhelmed with the complexity that any further development will be a pain.

    I was once in a team implementing a large-size healthcare software, with >500 KLOC, in which we did very little domain modelling, and we suffered a lot from that mistake.

    BTW, the author post another article "Why will LINQ fail?" in TSS.NET http://www.theserverside.net/news/thread.tss?thread_id=39460, in which he argues that LINQ does nothing more than today's ORM frameworks.