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.
Related
New year - new startup :)
We are chosing ORM. I personally worked with LLBLGEN last years.
I've looked through EF4 today and have found that its functionality is close to llblgen.
(filtering, sorting, grouping, working with stored procedures and functions, working with graphs of objects (prefetch path), lazyLoad).
I know that llblgen doesn't support POCO, that means that it is required to write additional (or more complex) code to decouple it from Domain.
I don't think that llblgen license is con as llblgen is real successful alternative to Microsoft's orms and it is cool that we have such alternatives.
I didn't find any concrete comparison of these orms in stackoverflow.
Just something like "If it is not critical to pay maney then use llblgen" :).
So I just want to list pros and cons of LLBLGEN and EF4. (ORMs functionality only without designers features)
I have used LLB on several projects over the last few years and I am just finishing off my first EF4 project.
Both are perfectly fine for simple 1-1 mappings between objects-tables. Doubtless other people would disagree, but for projects where I use codegen I try and keep that the case as far as possible.
I'm no EF4 expert, so theres probably things it can do that I've not discovered yet but I feel that LLB is a more mature product and the support is absolutely fantastic.
Surprisingly enough getting help on EF4 is nowhere near as easy and googling for the answers can be difficult because you end up with loads of unrelated C# hits. The LLB forums tend to give you detailed answers to your code snippets very quickly - normally within hours.
But MS being the huge beast that it is I had to give EF4 a try on a project, and things have worked out fine. But personally I still prefer LLB.
Pro for LLBLGen - support. Very responsive support forum with issues typically fixed in a day or 2 (or sometimes hours)
Try getting that level of support for EF (or any other ORM come to that !)
Ok guys. Let me summarize my question after studying EF4.
It is possible to use EF4 with POCO objects that is good if you are working with Domain model. LLB doesn't support POCO.
LLB entities has state even without dataContext (Adapter scenario). It means that you can get entity in one context and save it in another and second context will know that entity is not new. EF4 will treat it as new Entity and it is require to write additional code to mark it as updated.
LLB has SelfServicing scenario that is good for small applications as entities have self saving and lazy load functionality.
As mentioned above, LLB has great support. It seems the rule is to answer during 8h in workdays and 24h in weekends.
LLBLGen is so mature that it generates about six times as much code as necessary. Keep in mind that its first of many confusing and overcomplicated APIs had been designed long before the introduction of generics and LINQ and it shows. Starting a new project using LLBLGen is only understandable if you have already invested years in learning it. In all other cases do yourself a favor and forget it ever existed!
I am starting to delve into the realm of ORMs, particularly NHibernate in developing .NET data-aware applications. I must say that the learning curve is pretty steep and that a lot of things should be noted. Apparently, it actually changes the way you do data-aware applications, manner of coding, development and just about everything.
Anyway, I want to ask if you do set some parameters when deciding to USE or NOT TO USE ORMs in your applications? How do you decide then the approach that one needs to make it valuable to your organization?
The organization which I work for now apparently has made a lot of SQL and Data Access thing running through back end and I must say that these class/methods/procedures have successfully performed their tasks of providing the data which is needed and when it is needed. I think it would be a tremendous effort just to map some of this into ORM and derive the same business value that the company has for the last few years.
Nevertheless, I know that ORM paves the way for applications to talk with database servers, if properly implemented. I must admit that I am at a learning stage and that I would possibly need all the help, resources and the guidance to make this transition. I was also thinking of buying the book from Manning but I feel that with so much changes to NHibernate, the book may be a bit outdated. Perhaps waiting for the Packt book on NHibernate (release on May 2010??) would help me better get up and running.
Kindly share your thoughts. By the way, if you could also point me in a small sample web app which uses NHibernate + Visual Web Developer 2008 Express and SQL Server, that would be highly appreciated.
Thanks.
For me, the short of it is the following:
If you don't use an established ORM, and you develop correctly (meaning you refactor out duplication and look to simplify where you can), you'll wind up building your own ORM through the evolution of your data access layer.
The question then becomes:
"Do I want my developers spending time learning the idiosyncrasies of my home-grown ORM or learning those of a well-documented and well-tested ORM?"
Furthermore:
"If I'm hiring a new developer, wouldn't it be nicer to bring in a developer that knows the established ORM tool we're using rather than having to train someone up on this thing I built?"
I use NHibernate, particularly Fluent - and it's great; if given the choice, I wouldn't develop on an RDBMS any other way.
To be successful with an ORM you must make sure to normalize correctly, and use the database for it's designed purpose, storing data.
I don't use an orm when:
I don't use a relation database (Relational databases are not the best choice of database for every application)
The database is has a very small amount of tables. (I might need less code without an orm)
I use a very simple database that can map to code with simple naming
conventions. (Mapping to dumb DTO classes and all queries like select * from tablename where id=#id)
Learning a good orm is worth the time and effort, it will save you writing a lot of code when you use relational databases a lot.
You can find example apps/tutorials/video's about NHibernate on with stackoverflow search. There is another book in progress by manning, maybe it's possible to read it with the early access program.
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 really torn right now between using O/R mappers or just sticking to traditional data access. For some reason, every time I bring up O/R mappers, fellow developers cringe and speak about performance issues or how they're just bad in general. What am I missing here? I'm looking at LINQ to SQL and Microsoft Entity Framework. Is there any basis to any of these claims? What kind of things do I have to compromise if I want to use an O/R mapper. Thanks.
This will seem like an unrelated answer at first, but: one of my side interests is WWII-era fighter planes. All of the combatant nations (US, Great Britain, Germany, USSR, Japan etc.) built a bunch of different fighters during the war. Some of them used radial engines (P47, Corsair, FW-190, Zero); some used inline liquid-cooled engines (Bf-109, Mustang, Yak-7, Spitfire); and some used two engines instead of one (P38, Do-335). Some used machine guns, some used cannons, and some used both. Some were even made out of plywood, if you can imagine.
In the end, they all went really really fast, and in the hands of a competent, experienced pilot, they would shoot your rookie ass down in a heartbeat. I don't imagine many pilots flew around thinking "oh, that idiot is flying something with a radial engine - I don't have to worry about him at all". Everyone understood that there were many different ways of achieving the ultimate goal, and each approach had its particular advantages and disadvantages, depending on the circumstances.
The debate between ORM and traditional data access is just like this, and it behooves any programmer to become competent with both approaches, and choose the option that is right for the job at hand.
I struggled with this decision for a long time. I think I was hesitant for two primary reasons. First, O/R mappers represented a lack of control over what was happening in a critical part of the app and, second, because so many times I've been disappointed by solutions that are awesome for the 90% case but miserable for the last 10%. Everything works for select * from authors, of course, but when you crank up the complexity and have a high-volume, critical system and your career is on the line, you feel you need to have complete control to tune every query pattern and byte over the wire. Most developers, including me, get frustrated the first time the tool fails us, and we cannot do what we need to do, or our need deviates from the established pattern supported by the tool. I'll probably get flamed for mentioning specific flaws in tools, so I'll leave it at that.
Fortunately, Anderson Imes finally convinced me to try CodeSmith with the netTiers template. (No, I don't work for them.) After more than a year using this, I can't believe we didn't do it sooner. My team uses Visual Studio DB Pro, and on every check-in our continuous integration build drops out a new set of data access layer assemblies. This handles all the common, low risk stuff automatically, yet we can still write custom sprocs for the tricky bits and have them included as methods on the generated classes, and we can customize the templates for the generated code as well. I highly recommend this approach. There may be other tools that allow this level of control as well, and there is a newer CodeSmith template called PLINQO that uses LINQ to SQL under the hood. We haven't that yet examined (haven't needed to), but this overall approach has a lot of merit.
Jerry
O/RM tools designed to perform very well in most situations. It will cache entities for you, it will execute queries in bulks, it has a very low level optimised access to objects which is way faster than manually assigning values to properties, they give you a very easy way to incorporate variations of aspect oriented programming using modern technics like interceptors, it will manage entity state for you and help resolve conflicts and many more.
Now cons of this approach usually lies in lack of understanding of how things work on a very low level. Most classic problem is "SELECT N+1" (link).
I've been working with NHibernate for 2.5 years now, and I'm still discovering something new about it almost on a daily basis...
Good. In most cases.
The productivity benefit of using an ORM, will in most case outweigh the loss of control over how the data is accessed.
There are not that many who would avoid C#, in order to program is MSIL or Assembly, although that would give them more control.
The problem that i see with a lot of OR mappers is that you get bloated domain objects, which are usually highly coupled with the rest of your data access framework. Our developers cringe at that as well :) It's just harder to port these object to another data access technology. If you use L2S, you can take a look at the generated code. It looks like a complete mess. NHibernate is probably one of the best at this. Your entities are completely unaware of your data access layer, if you design them right.
It really depends on the situation.
I went from a company that used a tweaked out ORM to a company that did not use a ORM and wrote SQL queries all the time. When I asked about using an ORM to simplify the code, I got that blank look in the face followed by all the negatives of it:
Its High Bloat
you don't have fine control over your queries and execute unnecessary ones
there is a heavy object to table mapping
its not dry code because you have to repeat your self
on an on
Well, after working there for a few weeks, I had noticed that:
we had several queries that were almost identical, and alot of times if there was a bug, only a handful would get fixed
instead of caching common tables queries, we would end up reading a table multiple times.
We were repeating our selves all over the place
We had several levels of skill level, so some queries were not written the most efficiently.
After I pointed most of this out, they wrote a "DBO" because the didn't want to call it an ORM. They decided to write one from scratch instead of tweaking out one.
Also, alot of the arguments come from ignorance against ORM's I feel. Every ORM that I have seen allows for custom queries, and even following the ORM's conventions, you can write very complex and detailed queries and normally are more human readable. Also, they tend to be very DRY, You give them your schema, and they figure the rest out, down to relationship mapping.
Modern ORM's have a lot of tools to help you out, like migration scripts, multiple DB types accessed to the same objects so you can leverage advantages of both NOSQL and SQL DB's. But you have to pick the right ORM for your project if your going to use one.
I first got into ORM mapping and Data Access Layers from reading Rockford Lhotka's book, C# business objects. He's spent years working on a framework for DAL's. While his framework out of the box is quite bloated and in some cases, overkill, he has some excellent ideas. I highly recommend the book for anyone looking at ORM mappers. I was influenced by his book enough to take away a lot of his ideas and build them into my own framework and code generation.
There is no simple answer to this since each ORM provider will have it's own particular pluses and minuses. Some ORM solutions are more flexible than others. The onus is on the developer to understand these before using one.
However, take LinqToSql - if you are sure you are not going to need to switch away from SQL Server then this solves a lot of the common problems seen in ORM mappers. It allows you to easily add stored procedures (as static methods), so you aren't just limited to generated SQL. It uses deferred execution, so that you can chain queries together efficiently. It uses partial classes to allow you to easily add custom logic to generated classes without needing to worry about what happens when you re-generate them. There is also nothing stopping you using LINQ to create your own, abstracted DAL - it just speeds up the process. The main, thing, though is that it alleviates the tedium and time required to create basic CRUD layer.
But there are downsides, too. There will be a tight coupling between your tables and classes, there will be a slight performance drop, you may occasionally generate queries that are not as efficient as you expected. And you are tied in to SQL Server (though some other ORM technlogies are database agnostic).
As I said, the main thing is to be aware of the pros and cons before pinning your colours to a particular methodology.
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