What are the key differences between llblgen and nHibernate?
LLBLGen is an exquisitely case hardened tool that generates ultimately extensible code. Customer service is second to none and bugs are fixed as they are found by one of the finest minds in the business. I have had 5 hour turnarounds on obscure, affecting only me, bugs.
I am currently cutting my teeth on nhibernate and have to say that the apprehension that kept me from it for so long was not misplaced. It is a great tool with a huge user base but inherently, the mapping file / mapping classes / mapping attributes strategy is at the same time soft and brittle.
This is my opinion, no need for punitive downvotes because I am criticizing nhibernate.
LLblgen is a commercial tool, it uses designer based configuration to generate the classes for data access.
Nhibernate is an open source free tool that uses xml based mapping files to map your objects to the tables in the database.
I prefer Nhibernate over LLblgen.
Taken from the overview page of llblgen's homepage:
LLBLGen Pro, the #1 O/R mapper and data-access tier generator for .NET, generates a complete data-access tier and business façade/support tier for you (in C# or VB.NET), using an existing database schema set. In seconds. The generated .NET code is compiler-ready and can, being compiled by the .NET C# or VB.NET compiler, be used immediately by other applications.
So yes, its an ORM mapper as well, plus loads more.
Related
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.
I would basically like to know things such as:
Advantages/disadvantages between the two?
Similarities/differences between the two frameworks?
How are they similar/different architecturally?
How much boilerplate code is needed to use each?
Can the Entity Framework be used efficiently outside of Visual Studio compared to NHibernate? Is the Entity Framework more efficient than NHibernate when used with Visual Studio?
Note: This question refers to the Entity Framework 2 (currently still in development).
Disclaimer: This post is based on my current knowledge of what the next version of Entity Framework will be like. That might be inaccurate or it might change until the next version is actually relased.
General Approach:
The main approach of Entity Framework (EF) is using their graphical designer tool to create an Entity Data Model and to generate domain classes as well as mapping from that model. There is support for other approaches as well, but that way of working will probably always be the main one.
NHibernate (NH) is a text based tool which requires the user to write all the domain classes and mapping manually, if you don't turn to third party software for code generation, such as MyGeneration of CodeSmith, or additional convention over configuration support, such as Fluent NHibernate.
Code Generation:
Code generation is a major part of standard EF usage, either by using their graphical designer tool or by using their command line tools. The availability of both GUI and command line tools is a plus since makes EF easy to get started with as well as allowing for more advanced usage that can be automated, for example in a build process.
Code generation is not supported by NHibernate, except for the schema generation stuff if you want to count that as code gen. You can get code generation if you turn to third party software though.
Database Schema Generation:
EF will add support for model first development, by allowing the user to generate a schema from an Entity Data Model. NHibernate has had schema generation support for a long time. The difference here is how you create your "model", as mentioned earlier.
LINQ:
EF will have improved their whacky LINQ implementation from v1 and NH have now reached version 1.0 of LINQ to NH, so there should not be any major differences between the two in that regard.
POCO:
EF will add better support for the Domain Driven Design approach and the use of domain classes that are separated from the data access layer. However, since POCO is not the main use case of EF I can't really see how their POCO support could ever reach the level of NHibernate. The POCO support in EF is still young, and to me it feels more like that it is a bonus if you are a POCO/DDD supporter and you find yourself working on EF for some reason.
The entire NHibernate framework is build for POCO development, by DDD people, and they have reached version 2.1 as well as taking advantage of all the work put into Hibernate on the Java side. NHibernate will probably remain the no 1 choice for the DDD/POCO/ALT.NET crowd for quite some time.
Lazy Loading:
The next version of EF will include support for automatic lazy loading. Automatic lazy loading has been an important part of NHibernate for a long time.
Learning Curve:
Both frameworks are complex and powerful, and hence take a long time to master. But EF is quite beginner friendly since it is integrated into Visual Studio, with its graphical designer tool, and since it can generate a lot of stuff for you without you having to know just about anything about the framework. However, if you want to dig deeper into EF and really learn the framework, you should be prepared to spend quite a lot of time using it.
NHibernate has a notorious learning curve, but some recent improvements have reduced it a bit. Now that LINQ to NH is at v1.0 the query syntax will be easier to understand for developers new to NH, and the Fluent NHibernate project is improving the mapping experience, and even working on automatic mapping, which is getting better and better all the time.
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.
I need to collect some information about existing ORM solutions.
Please feel free to write about any programming language.
Can you tell about the best ORM framework you ever use and why is it better then others?
I used NHibernate and Entity Framework.
Current stable version of entity framework is very immature. It is too difficult, or impossible to perform common tasks. Testing your code is also difficult since you cannot really separate your entities from your data access classes. But it perfectly integrates with visual studio ide. Setting up is easy and updating all the models from database takes just a few seconds. Upcoming version of EF (4.0) will solve some of this problems.
NHibernate is quite powerful. It supports plain old clr objects, so you can work with simple entities. Configurations provide great control in great detail. Framework capabilities are satisfying and it has a large and active community and good documentation. Setting up and updating entities is a little difficult since you must use generators that looks up your database and generates entities and xml files. It may be tricky to find a generator or a template that exactly fits your needs. But once you set all things up, you will love it.
I found LINQ to SQL to be a pretty straight forward solution. The first time I used it, I'd say I had a basic ORM working within a few hours, and was creating LINQ queries with it.
Microsoft has an additional ORM (Entity Framework), which I've heard is more complex but may be useful for highly complex distributed applications with multiple data sources etc.
Overall I found LINQ to be an easy and fast to use ORM.
I have been looking at Telerik Open Access for last few months, in genernal this ORM has been a pain to work with, it was advertised as having extensive linq support but in reality many of the linq features you would normally expect dont work server side and are performed on the client. I also had problems using multiple conditions in a where clause, see my last question. Here are a few things that i found
No support for views
Unable to map more than one entity to the same table
Inheritance and Interface support requires you to make changes to you database schema
No visual designer like LINQ to SQL and Entity Framework
If you want to perform an insert any related entities must be fetched first
Rohan
LINQ2SQL was nice, EF makes sense, but is very complex and SQL Server oriented. NHibernate is special and Telerik OpenAccess (fully .NET / Visual Studio) got a broad set of functionality and professional support.
Since I know the product I can comment on Rohan's concerns:
Existing Views can be used and full Views support is coming up
Mapping more than one entity to the same table "works" for class hierarchies, limitation with reverse mapping exists
Inheritance and Interfacer support "do not require" changes to the the database schema, again limitation with reverse mapping exists though
Visual Designer will come, Forward and Reverse Mapping Wizards allow you already to do anything in an easy way
There is a workaround for the insert issue mentioned and it will be fixed generally
Check out the Telerik site to find happy customers and feel free to use the telerik forums and support resources for any question.
-Peter
Im new to OpenAccess ORM and we are using two products. Reporting and OpenAccess.
I think there are some features that people missed.
OpenAccess uses graphical designers while nHibernate still uses handwritten xml files
OpenAccess is not limited to SQl Server as EF4 and similiar frameworks
using it is easier and the forums are pretty helpful.
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster
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