-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Recommendation pro or con NHibernate
PostPosted: Mon Feb 15, 2010 10:20 am 
Newbie

Joined: Mon Feb 15, 2010 10:07 am
Posts: 2
Hi everyone,

I am evaluating ORM libraries for a new project that we are doing and I was wondering whether some of the experts here can give me a recommendation pro or con NHibernate. I am going to list our key requirements that arise from the project. It would be helpful to get an indication as to why the recommendation that you give is pro/con, i.e. which if the requirements are fulfilled pretty naturally and which are really problematic. The priorities are given as Pn, where P1=must, P2=should, P3=nice to have

Thank you in advance!

1. (P1) Generalisation from Oracle DBMS is not an issue
- the application does not need to run with any other DBMS than Oracle
- So it is not a benefit for an ORM to be good at as many DBMS as possible.

2. (P1) Offer a concept for data model upgrades and data migration
- The OO/data model will change from one deployment at the customer's site to the next
- At best, the changes of the model are deployed through the ORM, not by-passing it with hand-made SQL scripts
- So the ORM must allow for the data model to be versioned and to trigger version upgrades in a database from the application
- The ORM must allow for the data model to be designed such that a current build of the application/the OO model runs with an older version of the database, of course with limitations as to the missing changes between the old and current data model version.

3. (P1) Allow for dynamic enhancement of the data model at RUNTIME.
- A portion of the data model is dynamic, i.e. prone to changes
- Users define new entities in an application session
- The application will deduce data model changes according to the standards of the ORM
- The dynamic portion of the data model is as sensitive to performance as the static portion
- An approach that will put properties in generic standard tables according to their type or other criterion is not sufficient

4. (P2) Derive data model from OO model
- It does not matter whether via XML, attributes or other means

5. (P2) Allow for data model optimisation
- Fine-tune indexes for statement performance
- Control physical data model properties such as the tablespaces in which tables, indexes, LOBs are stored

6. (P3) Rid OO developers of the need to write SQL statements
- Focus all persistency-near code in a small group of classes
- ORM should be easy to exchange by only changing the implementation of this small group of classes


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.