ORM tool OR build the object to relational mapping layer manually

I am trying to determine what if any advantage or disadvantage there is to using an object to relational mapping layer like hibernate or the Microsoft Entity framework when building the data layer.

Is using sql and mapping objects by hand better in the long run or is it better to leverage one of these mapping technologies?

It seems like 开发者_Go百科for simple apps the additional mapping layer might be advantageous because the tool can handle the simple mapping and sql therefore saving some time, but what about when your object models become more complicated?

Also what are the performance implications if any?

Thanks for any insight you might have.

Your best option is to ensure that whatever you do, you keep the ability to change it later available. So if you go NHibernate or EF, you'll want the actual dependencies on the frameworks kept in a very tight are; same for manual-implementations.

Try implementing the Repository pattern, you could then build an NH-repo, EF-repo, etc, etc. and see which fits yours needs best.

My personal opinion is to do proper OR-Mapping (whether by hand or by framework)--the implication here is that your business/domain objects do not just look like your tables, and vice-versa. The whole point of an ORM isn't just to get data out of the database and into your application (DataSets were fine for that), but to let you take advantage of the best-of- both-worlds of OOP in your application and an RDBMS in your backend.

If you're just using SQL as "dumb-storage" (my favorite usage of it) then you could consider using an OODB or other object-persistance approach. This is always a fun thing to explore in hobby/side projects--but it's a hard case to sell to management (they looove their SQL Server), but it's worth a consideration.

Of course, if you're talking very small application, then perhaps you could implement something either following the Active Record pattern or perhaps the Transaction Script pattern--XScript is great for very small apps, but doesn't scale well--and Active Record is perfect for data-entry/CRUD applications

It seems like for simple apps the additional mapping layer might be advantageous because the tool can handle the simple mapping and sql therefore saving some time, but what about when your object models become more complicated?

Actually, I'd say it's the other way around.

It makes more sense to use an ORM in a larger application that has a complex object model:

• For very small applications with a simple DB model, an ORM is probably overkill, since the persistence layer will be rather easy to implement without introducing bugs somewhere, and an ORM won't save you much work.

• On the other hand, with a large application having a more complex DB data model, it's easier to get your JOINs and your UPDATEs etc. wrong, so an ORM might really be helpful.

If this is a question of "should i use an ORM or not?" then there is no absolute answer to your question, each approach has trade-offs, both positive and negative aspects.

ORMs can help you get up and running pretty quickly, especially if you have a larger data model. They can also be excellent if you need to generate several different persistence layers because you support multiple database vendors with the same version of your product. ORMs are not as bad as they used to be, they are reasonably efficient these days.

Personally though i'm not a fan of them - i think that if you are halfway proficient with your database skills then you should use them. I think that ORMs tend to shield developers from database complexities, which is not necessarily a good thing. I like to tune my data access and storage, and while writing code to map datasets to domain objects can be tedious it isn't that hard or error prone and i know exactly what is going on at all times, there is no magic happening anywhere. If there are performance problems or inefficiencies then i can very quickly track them down and fix them.

You could build your own ORM mapping tool. For example here http://askcodegeneration.com/php/generate-propel-schema-for-php-symfony/

A propel orm schema is generated from a simple description class format (nothing prevents to do it for any other language like c# and any orm framework like Hibernate, in fact in the future I intend to do so):

class-list: [question answer user interest relevancy]

Sample-Model: {

  class question [

    Id: 0
    title: ""
    body: ""
    created_at: 'now
    updated_at: 'now
    user_Id: [User]

  ]

  class answer [

    Id: 0
    question_Id: [question]
    user_id: [user]
    body: ""
    created_at: 'now
    updated_at: 'now

  ]

  class user [

    Id: 0
    first_name: ""
    last_name: ""
    created_at: 'now
  ]

  class interest [
    question_id: [question]
    user_id: [user]
    created_at: 'now
  ]

  class relevancy [
    answer_id: [answer]
    user_id: [user]
    score: 0
    created_at: now
  ]

}