Hello All
I am planing to use Nhibernate in Dotnet 3.5 application.This application is like an enterprise application which will provide core services to all other application of my company. So my question is:
Is Nhibernate is right choice with this kind of application?
Are there any performance issues with Nhibernate?
NHibernate is good for any kind of data access applications.
As for performance its good enough for most of the apps. The only thing where I think it won't fit is synchronization tasks where really tons of data could be transferred. For that kind of work any ORM would suck.
I know of many places that use Nhibernate for Enterprise and mission critical application and are satisfied.
Nhibernate supplies an object oriented abstraction to data base entities. if you're comparing them to equivalent SQL operations, the performance penalty is negligible.
However, when using more complex operations, mainly on large sets of data, native SQL may perform significantly better.
NHibernate is the probably the right choice. The library is very mature (currently v3), based on java Hibernate which is there for even longer.
It depends. NHibernate is designed for OLTP scenarios. That means you load some small chunk of data, process it and you save it back. Critical part is: "small chunk".
If you find yourself in any OLAP-like scneario where you must batch process large chunks, NH is not a good choice. In such situation you most likely don't want to use any ORM at all.
As always: Right tool for the right job.
If your application is a typical enterprise like, you will be happy with NH. The library is extremely flexible with many fine-tuning options. Also remember that you can still use plain old ADO.NET in OLAP parts of your app if there are any.
If you run into any problems, NH community is very supportive plus there are companies and individuals offering consulting and paid support (in case your company policy requires it).
I'm using NH for 3 years and I can recommend it - the tool does its job.
Related
I have to prepare a case to convince managers to promote development using an ORM. I don't want to go into technical details in this case, the benefits have to be visible to business people.
I'm not quite happy with the arguments I've written down until now Are there any points I'm forgetting, both PRO and CONTRA?
The case I'm going to make will be in two points:
Convince managers to use an ORM
Convince managers to use NHibernate
The PRO's for ORM:
Solves the impedence mismatch between a rich ecosystem of connected objects with behaviour and tablular lists of scalar values
Higher productivity => reduced time writing tedious data access code lets you focus more on solving 'real' business issues
Higher maintainability => reduced number of LOC == system is easier to understand (hmm... maybe...)
Almost no performance hit when used right
The CONTRA's for ORM:
O/R mapping tools do not perform well with bulk processing of data. Stored procedures may have better performance, but are not portable
Heavy reliance on ORM software has been pointed to as a major factor in producing poorly designed databases
The PRO's for NH:
Very mature produce
Supports a lot of DB's => developers don't have to learn a new SQL dialect on every other project
High mind-share amongst .net community leaders
Many examples, articles, blog posts
It's open source
The CONTRA's for NH:
Not suited at all for batch processing
No code generation or code designer => some people think this makes developers more productive
Bad reputation due to lazy coding (== abuse of lazy loading)
It's not from Microsoft
It's open source => some companies just don't like that
Business people typically think in terms of cost and deliverables. Beyond that, most don't grasp or care about the technical reasons.
You already mentioned the higher productivity aspect.. try phrasing that as spending more time on business rules and less time on repetitive CRUD code.
I'd add, and highlight this:
Lower development friction makes meeting deadlines easier
Reduces cost of development in time spent working with the database
Reduces cost of maintenance
NHib is flexible; can handle object mapping automatically, and allow specific queries/stored procedures when needed
Also checkout Fluent NHibernate and Fluent Migrator.
I'd actually like to rebuke some of the negative points.
O/R mapping tools do not perform well with bulk processing of data. Stored procedures may have better performance, but are not portable
NH has many optimizations for bulk data processing (batching and caching are the first that come to mind). And you can always add stored procedures for some cases, it's not an "all-or-nothing" proposal.
Heavy reliance on ORM software has been pointed to as a major factor in producing poorly designed databases
I've actually seen the opposite: supposedly optimized DB-first designs that fall apart when the real use cases are implemented. In any case, it's a developer failure; you can do poorly with or without an ORM
Not suited at all for batch processing
Absolutely not true. NH has many features specifically designed for batch processing, like Stateless Sessions. Of course it's hard to beat the performance of a SP running in the DB server, but apart from that, it'll usually do just as well as adhoc ADO.NET code.
No code generation or code designer
False. There are several products that provide that. Check http://nhforge.org/wikis/general/commercial-product-ecosystem.aspx
Bad reputation due to lazy coding
If you do SELECT * FROM TABLE it will perform badly too. I fail to see how NH is to blame.
It's not from Microsoft
Neither are Oracle, the iPod or BMWs, yet people use them
It's open source
There is commercial support available. And, unlike what happens with MS products, the support is provided by people who know the internals and can fix them in a few hours instead of a few years.
When your manager decides which technology you have to use, your manager should be able to understand the technical reasons. Otherwise, he should trust the developers (they have the knowledge to make the decision) to decide. I can think of more useful things for a manager than making technical decisions he does not understand enough.
When your boss is like Dilberts pointy haired boss, I would go for the time and money saving argument (for every technical decision the manager wants to be involved in).
Take a look at this list of features of a real-world ORM. For any non-trivial project you will eventually end up using 80%+ of those features. So, either you can build those features yourself or you can use NHibernate. If you choose to build it yourself, be prepared to invest about $7.5M and 140 person years.
Or you can just use NHibernate, save the money and effort, and benefit from the huge knowledge base available on the net, books, community, etc, and even use (if necessary) one of the high-quality commercial support providers available.
You need to express it in terms of time and money - impact on development and maintenance time and impact on user time. ORM use is way too often the cause of a system that is strangling itself in poor performance (and which is now too far along the design path to change), so you need to address to the managers how you intend to avoid doing this. Frankly dev time and maintenance time are peanuts compared to wasted users time from bad implementation of an ORM. Yes it can be done right to avoid that but it usually is not. Often this is because the devs who use ORM don't understand databases and don't want to understand databases. ORM in the hands of a database expert, good thing, ORM in the hands of an application programmer who can't write basic SQL and who doesn't even understand joins, disaster waiting to happen.
No code generation or code designer
As Diego pointed out, there are third party tools. However, I would like to stress that NOT having to use a designer is a strength of NHibernate. Designers typically don't scale in the following ways:
What good is a design surface when an application has many, many entities? A visual designer just slows you down with noise at that point.
Designers typically have issues with merging. They work great when only one developer needs to edit the model at a time. The more devs you have on a project, the more potential trouble there is for merging the designer files.
This is probably a long shot.
In the .NET world, has anyone found an ORM (Commercial or Open) that has the flexibility of NHibernate to support domain driven design with good Linq support? Linq to sql is dead, Entity Framework doesnt yet support POCO's, lazy load or object first development very well, and none of the old stand bys such as LLBLGen seem to either.
Anyone find anything new and exciting in the ORM market?
Thanks!
See ORMBattle.NET - it won't exactly answer your question (btw, I hardly admit this is possible), but there is some info on quality of LINQ support.
Note (or disclaimer): I'm one of persons related to creation of ORMBattle.NET, as well as one of DataObjects.Net authors.
Which version of the .NET Framework are you talking about? 3.5? 4.0?
There are quite a few ORMs out there and some of the commercial ones may in fact meet your needs (or be working on new releases that meet your needs). Competing against both NHibernate and Entity Framework from a commercial perspective is pretty daunting. Microsoft made it much harder than necessary to write a Linq provider, which is why so few ORMs have one. Writing a domain driven design oriented ORM that supports multiple database vendors is also a pretty steep hill to climb.
NHibernate certainly has all the momentum right now, but that doesn't mean it's invincible. It's hard to compete with free & open source software that has a multi-year head start, even for a company with the financial resources of Microsoft.
I think you may just need to be patient. NHibernate's Linq provider is improving and the other ORM vendors are working hard on improving their offerings as well. Things could change significantly in the next two years or so.
No, I don't know of any. Because NHibernate is popular and very good at what it does, and EF is likely to pick up most of the remainder (particularly devs that don't want to stray from Microsoft-supplied frameworks), the barrier to entry for a new player is very high. Another ORM would need to add something significant over and above what NHibernate currently offers in order to get any reasonable level of interest.
If there was an open source project that wanted to deliver better Linq support in an ORM, in my opinion it would have greater success contributing to NHibernate Linq rather than attempting to build its own framework from scratch.
I wouldn't call it a "NHibernate killer", but SubSonic works well. It's simple to use, allows you to choose between using the Active Record pattern and the Repository pattern. It supports POCOs, lets you use object-first development and setting up lazy-loading is easy enough.
CQRS could be considered an NHibernate killer. The basic premise is that your domain objects are not used to support your read model and application queries. As such, you can start using something more like a document store to hold your aggregate or even use event sourcing. To update your read model, you have it listen to the events published by your aggregate so that it can update itself accordingly. Using this architectural style we have been able to eliminate the our reliance upon NHibernate. Now if we decide to use an RDBMS, it's because of the strengths of the database rather than as the default choice.
I am trying to work out with ORM tool to move over to and have narrowed it down to two candidates.
nHibernate or LLBLGen Pro
Please can you guys give me pros and cons in using both these tools especially if you have experience in both. I am not really interested in any other tools but am wanting some heads up so I can decide which tool to spend time learning....
I already know that one is free and one isn't, I also know that nHibernate might take some learning....
Many thanks, Richard
I have used both. At first I was sold on nHibernate and refused to try anything else even though I knew about other options.
With LLBLGen Pro, I was skeptical, but soon saw the advantages as well. I have not totaly abandoned nHibernate. I will continue to keep int in my "box of tools". I have found LLBLGen useful in some cases especially when interacting with a database that already exists and you have no choice of re-designing it. It takes less than an hour (depending on size of database of course) to generate my LLBLGen Entity Objects from the database, as opposed to having to code all of it manually with nHibernate, AND do the mappings. nHibernate is missing a nice graphical interface to create the mappings. This fact becomes even more important when the database is massive with thousands of tables that you need to potentially access in your application.
Although LLBLGen is more of a Data Access Layer generator (And I am not normally a fan of DAL generators), it has a lot of features a "true ORM" tool would have. In my opinion it has the best of both worlds. Once you start working with it you start to realize that it is very flexible and extendable. One part I like a lot is that it is possible for me to create partial classes for the generated entity objects, where I can code in my business logic, as well as validation.
The code generation is templated so you have full control over the code it generates. With nHibernate I find myself writing some of the same kind of code over and over again. With LLBLGen I can generate it and get to focus on business logic and issues quicker.
For someone who is just starting to use ORM type tools, I really recommend to start with LLBLGen, because nHibernate can be overwhelming. And in the end you will have achieved the same result (More or less).
Edit #1: LLBLGen now also has 100% support for LINQ. (So if you like LINQ to SQL for that reason) further LLBLGen can support many databases, where LINQ to SQL is only for Microsoft SQL Database.
Edit #2:
According to Graviton you can use CodeSmith to do some of the code generating for you for nHibernate. That is really cool, but for a newcomer to ORM I would still recommend LLBLGen. To me that is adding more dependencies where LLBLGen has it all in one package. Also like I said before the learning curve is so much less steep and you will get the same benefits, which will also help you ease in to nHibernate if you ever decide to go there.
The major difference is that LLBLGen is a code generator, while NHibernate is a "true" ORM library.
LLBLGen advantages:
Easy to use model designer. Can import your existing database schema
Fully typed object model and query language
LLBLGen disadvantages:
You need the designer application to change your model
Not free
Can bloat your code because a lot of code is generated
NHibernate advantages:
No designer application needed. Only code
Widely used (based on the most popular Java ORM, Hibernate)
Very powerful for mapping any data model you can imagine
Open source
NHibernate disadvantages:
Hard to learn
Not as strongly typed as one would like (especially queries)
Of course, this is just my personal point of view...
I typed up a fairly long answer before realizing this was a somewhat old question. Oh well. It's still very relevant.
You have narrowed your list to the two best candidates for an ORM in the .NET world. I have limited experience with either, but I've read extensively about the pros and cons of both. They really serve somewhat different needs in different ways.
In the upcoming LLBLGen Pro 3.0, Frans Bouma has talked about adding features to generate NHibernate mappings. So, it's not even necessarily an either/or decision.
If you want to do "class first" design (as opposed to "database first" design), NHibernate is pretty much your best and only option right now (neither LLBLGen Pro nor Entity Framework support this mode, although it sounds like Entity Framework is improving it's support in the next version).
NHibernate and LLBLGen Pro both work hard to work well with legacy databases which you can not change and have to live with. That is their common strength. They both also work with Linq. They both also support some amount of graphical modeling, although LLBLGen Pro is far superior in this regard (ActiveWriter for NHibernate feels like the LinqToSql designer in Visual Studio, but it's not really as feature rich).
LLBLGen Pro has much stronger code generation abilities, but too much code generation can lead to compromised testability and maintainability (one small tweak can cause massive amounts of code to need retesting).
While NHibernate wants to help you work through fairly complex object/relational mapping scenarios like class inheritance, LLBLGen Pro is really just exposing your database as a data layer and business objects in a very quick way.
If you can purchase LLBLGen Pro and have some time, I would try both and see which one better meets your needs. Learning both ORMs is good for your resume in any case.
So, in the end, I would say it's situational. The cost of NHibernate and its lack of serious flaws make a pretty compelling case in the majority of situations.
The new version of LLBLGen Pro (3.0) allows you to generate code for NHibernate, so don't have to choose :). It also allows you to split up your entities into different domains.
I still prefer the LLBLGen pro runtime though, the LINQ interpreter is more complete and it has better change tracking of fields.
Unfortunately there's not many new features in the new LLBLGen Pro 3.0 runtime, as the creator first wanted to focus more on tooling than improving the existing framework.
I've used nHibernate, LLBLGen Pro, a custom data layer from my consulting company, the Enterprise Library, and LINQ. LLBLGen is by far my favorite and it allows writing one business layer that can talk to different types of databases using the same code providing database independence! Another incredible feature is it allows multiple connections to different databases. This is very useful when at a large company and one system is written in Sql Server and the other you have to interface with is in Oracle.
LLBLGen Pro is an amazing product backed up by Frans who is very active and works hard to fix issues. LLBLGen is like PhotoShop, it is an incredible tool and that can do amazing effects in the hands of someone who knows how to use. And like any tool that saves lots of time, it takes a week or two to learn how to use it, but will save months later on your project.
Not only did it speed up the DAL generation side of my app, it is also easy to create queries in the Business layer and send to the presentation layer. It made it easy to create an enterprise class application.
If one really wants to use nHibernate, start with LLBLGen Pro and generate the nHibernate code. If later on your department decides to switch from nHibernate to LINQ, you are covered. Want to switch from Sql Server to Oracle? This is possible and relatively easy with LLBLGen whereas with manually coded nHibernate code, you have to rewrite everything which is almost impossible to cost justify.
Frans was also available and answered some of my questions.
Don't forget one of the greatest plus point of Hibernate: HQL. With HQL, your SQL skill is not wasted. And Hibernate provides very nice, seamless support for native query as well.
If you have some weird, out-of-standard database, it's almost certain that you need your SQL skill at some point, and good luck with LLBL!
For me it boils down to database centric (LLBLGen Pro) vs. domain model centric (NHibernate).
Since I'm a DDD/OO guy, the choice has always been very easy for me, but I do see why LLBLGen Pro is popular.
We use LLBLGen at work, and it's reviled -- namely because we have multiple similar schemas, but you need to have a different DLL/Class library for each schema, meaning that it becomes annoying to write code that can target any schema.
Of course, that's an unusual environment, so it may not apply to you.
What are the advantages/disadvantages of using NHibernate ?
What kind of applications should be (& should not be) built using NHibernate ?
Since other ppl have listed advantages I will just list the disadvantages
Disadvantages
Increased startup time due to metadata preparation ( not good for desktop like apps)
Huge learning curve without orm background.
Comparatively Hard to fine tune generated sql.
Hard to get session management right if used in non-typical environments ( read non webapps )
Not suited for apps without a clean domain object model ( no all apps in world dont need clean domain object models) .
Have to jump through hoops if you have badly designed ( legacy ) db schema.
Advantages:
Flexible and very powerful mapping capabilities.
Caching.
Very polished UnitOfWork implementation.
Future query (article).
Model classes are POCO - which effectively means you can easily implement anemic domain antipatter.
Interceptors - you can do a kind of aspect oriented programming... Like very easily implementing audition, logging, authorization, validation, ect for your domain.
Lucene.NET and NHibernate are well integrated with each other - gives you a very fast and effective implementation of full-text indexing.
It's very mature and popular in enterprise environment.
Big community.
Disadvantages:
Already mentioned learning curve. You can start using NHibernate very fast but it will take you months to master it. I'd highly recomend to read Manning NHibernate book.
Writing XML mapping can be very tedious especially for big databases with hundreds and thousands of tables and views and stored procedures. Yes, there is tools that will help you by generating those mappings but you still will have to do quite a lot of manual work there. Fluent NHibernate seem to simplify this process by getting rid of XML mappings, so is Castle ActiveRecord (AR though is impossible to use for anemic domain as you define mappings in attributes on your model classes).
Performance may be low for certain scenarious. For instance large bulk operations. For those you might have to use IStatelessSession but its awkward experience, least to say...
Advantages:
Open source
Based on widely approved patterns
NH is not code-generator :)
Disadvantages:
Half-done LINQ support
Low performance
(see for example performance and LINQ tests on ormbattle.net)
Advantages:
Caching
Simplicity in your code
Power
Flexibility
Multi-database support
Disadvantages:
Stops you having to write your own persistence code
May reduce your knowledge of SQL
Applications you should use it for:
Any that use a database
A few more specific reasons to like NHibernate
Disadvantages: NHibernate is not a Microsoft product and therefore will face some resistance from coworkers who haven't heard of it. Especially FOSS bigots. Configuring the mapping files and lazy/eager loading behavior can be time-consuming. If your database has a bizarre naming convention, atypical design or very strict performance requirements, more work may be required than expected.
I say this a lot but ActiveRecord is a great layer over NHibernate. It uses attributes to map the data points to class members right in the classes themselves. People are not using this thing enough.
The high level answer is that NHibernate is in a class by itself and there is no near competition.
If you need CRUD against a database from a .NET application, you should be using NHibernate, for at least two reasons:
1) You get Linq support (which requires something like an ORM)
2) NHibernate is very mature
There are no significant disadvantages. There are other options, but those other options have significant disadvantages.
I wrote some more on this a while ago:
.NET and ORM - Decisions, decisions
For those who know the inner workings of nhibernate, do you think a large scale web application like say facebook/myspace would use nhibernate?
Or is nhibernate well suited for more low traffic sites like company sites etc? i.e. not enterprise ready because of its chatty nature?
NHibernate is not chatty at all. About scalability, there was already a question on NH's groups, which was more about the complexity of the database then traffic, but might still be interesting for you.
Even if there are always complaint's about unnecessary queries on every ORM, because of the generic nature of an ORM, it doesn't mean that it is chatty. On the other hand it optimizes situations where it would be too complex to optimize in hand-written DAL's. Eg. query batches or lazy loading.
NHibernate is quite light-weight compared to other ORM's and compared to it's powerful features.
NHibernate (as any other ORM) could be considered to be overkill if there is no object oriented business model but you need to optimize for highest performance. I don't think that Google could make use of NHibernate for its search engine, for instance.
Edit:
The performance and power of NHibernate is not fully for free. It requires that the developers understand at least the basics about relational databases. Other ORM's try to hide the whole relational problematics, which leads to much more unoptimized behaviour.
nHibernate is a professional joke.
In my company, its use has been prohibited by several reasons.
As tool is quite unproductive; you'll spend countless hours trying to figure out, or finding alternate strategies in a scarce documentation.
Much better, use your own generated DAL and SP's to achieve high performance. You'll have a cached execution plan, and in the end that's what really matters.
nHibernate has no advanced support for memcached, which is specially what you are going to use if you want to build a scalable web solution, like Facebook.
I work for a social gaming company, and we have specially forbidden to use nhibernate in particular.
NHibernate supports query caching, 2nd level caching based on primary keys, and also session cache for repeated hits on the same entity within the same session.
That's all a great help, but as long as you are hitting a database with a large load, you are going to have scaling problems. The best way to scale a database is to minimise the amount of time you actually have to use it. Distributed cache such as memcache, and caching your output (either post-datacrunched views or html) are the best ways to scale an application. If clients are regularly hitting the database, you are doing it wrong, ORM or not. In a .NET application, like a typical MVC app, has the advantages of being able to use varyby output caching, donut and donut-hole caching, as well as clients for memcache to be used with NHibernate and for your ViewModels.