The subject of this question speaks for itself. I am wondering if Fluent NHibernate is ready for production code. I am especially wondering in light of some seemingly simple problems that I am having with it that I haven't yet found fully satisfactory solutions for (and the community doesn't have a solution for?)
Why is Fluent NHibernate ignoring my convention?
Why is Fluent NHibernate ignorning my unique constraint on a component?
Yes, I am aware of this old question which is more than a year old; the answer seems to be kinda-sorta-maybe.
Is Fluent NHibernate is ready for production now?
By what metric do you measure "production ready"? How is production any more stringent than other environments? Only you can decide if it meets your needs.
Your first question you have a work around for. Fluent NHibernate is open source, if people aren't dying because of a bug (aka, there's a work around available), it's unlikely our finite resources will be spent on it when there are more important things to be working on. Enums are a known issue, primarily because 50% of people expect them to be mapped as ints, and the others expect strings; either way, one party is going to think that the implementation is a bug.
Your second question looks like a bug. Funnily enough, the Fluent NHibernate developers don't trawl Stack Overflow for possible bugs. If you don't tell us that a bug exists, we won't be able to fix it; sadly, I'm not psychic.
Fluent NHibernate has is past 1.0, which is quite a significant milestone for an OSS project, and is in use in hundreds of production applications. Whether that makes it "production ready" can only be decided by you.
If you don't think it's production ready yet, it's open source and we're always looking for contributors.
This kind of question really should be asked over on their google group page: http://groups.google.com/group/fluent-nhibernate. Being an open source project that is constantly evolving with NHibernate itself, it will almost always be in a semi-flux state, especially with NH3 coming soon.
Do you have unit tests that cover the scope of the functionality of your interaction with Fluent NHibernate? If you do, and they work, then why worry about other features that don't work that you don't use. Besides, a lot of issues with any open source project is lack of understanding of how to use it.
Related
I am in process of evaluating ORM first time. Please suggest which one i should choose for my next project.
I wrote couple of sample code with EF 4.1 code first. Before start same exercise with Nhibernate, I want to know if somebody have already experience with both in production application.
My evaluating criteria
Speed of database access
Learning curve (because I am new to ORM)
Community support
Tutorial/Books availability
Anything else which I should consider (Because I am noob to ORM)
I wish if people who have experience with both the ORM in production level app answer my question.
Thanks in advance!!!
I am aware that this question may be a little bit dangerous to ask ;)
Having used EF 4.1 and Castle ActiveRecord (based off NHibernate), I would rate them as follows:
Speed of DB access - NHibernate for anything remotely complex, otherwise about the same. The problem with EF is that it creates such convoluted SQL that it's difficult to know how to optimise it or if it's even possible to do so.
Learning curve - I personally found EF easier to get started with, but others may feel differently, and both certainly have a learning curve.
Community support - Depends on what you mean by 'support'. You'll find lots of info on the web (and this site) for both. NHibernate is open source, while EF is controlled by MS.
Tutorials/Books - I believe there are more 'official' resources available for EF at this time, but searching on forums will likely get you what you can't find in books.
Anthing else - Realize that the purpose of ORM's is to simplify the data access layer for the developer. However, both of these ORM's (and pretty much every other heavyweight ORM) expect you to use certain coding patterns for this simplification to be realized. While coding pattern enforcement isn't a Bad Thing (some would argue that it's a must), it's something you certainly need to prepare for before choosing one.
If you are a noob to ORM and only need the basic features you may find the Entity Framework and Nhibernate are over kill and should be looking at a light weight one like Massive:
https://github.com/robconery/massive
That said there are two main issues you face with EF vs NH
EF is all that microsoft support and so all their tooling by default uses EF. Making beginner code easier with EF.
NHibernate is more mature and has a greater feature set (if you need it) also has a good development community and lots of blog info about it.
I would choose Massive if you want simple / fast but unsupported, EF if you want easy and MS support but limited in some ways, or NHibernate if you have the time to learn a proper ORM.
Hope this helps.
Well im my personal experience Nhibernate have been the right choice, in complex situation have given me better time results, and it was a lot easier to learn.
I learned it first and then tried the Entity Framework and I found it easier to learn nhibernate Even though in that moment i didn't knew anything about ORM.
Community support and Tutorials and books I can say they are both good and have a lot of material to learn from.
Now I can use them both but still likes Nhibernate a lot more.
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!
While this is a subjective question, as a new NHibernate user, I'm curious as to why one would choose Fluent vs traditional XML mapping.
From my standpoint, when I first worked with NHibernate, I used the Fluent interface, but ran into some roadblocks and had a hard time finding adequate documentation for the Fluent interface for anything beyond a 'toy app', so I learned to handle these via XML.
Over time, I realized I did most of my work on the XML side, and realized it was not as horrific as I thought it would be. So for me personally, it was a case of poor documentation and not seeing a significant savings in coding time.
That being said, there may be some huge advantage/disadvantage that I'm missing, and I'd really like to hear some opinions from folks who have more experience in working with these tools.
Compile-time safety and refactoring (renaming classes, properties) are one of the benefits you get from fluent mappings. Using one language (C# or VB.NET) to write mappings, program code and data access is another benefit.
Compile-time name- and type-safety
IntelliSense to show you which fluent methods are available at any point
Customizable defaults
Automapper
For me, the big feature in Fluent is the Automapper.
I can define my domain model using POCO classes, (mostly) without worrying about the nasty details of how they will be mapped to tables in a relational database.
As a long time OO developer, and occasional DB developer, I'm much more comfortable designing in an OO fashion. I also believe that this allows me to work at a higher, more powerful level of abstraction.
Automapping also makes ongoing changes to the domain model much less daunting.
Your customers have just told you at the last minute they want to add four new columns to the database?
No problem - add four new properties to the associated POCO (4 lines of code), and remap.
Takes a lot of the pain out of the constantly changing requirements that are a fact of life on many projects.
I'll add a reason that is very important for making custom functionality based on a common code base:
With fluent you can override mappings to add a new field. Changes to the existing (superclass) mappings are automatically incorporated into the customization/branch. I was forced to use Fluent to avoid maintaining a seperate .hbm/xml file for each customer. Glad I did :)
Like a lot of open source software, this library was available to the public before a lot of the features were production ready. Depending on what version of FluentNhib you were working with, some features may not have been implemented at all. For example, when I first started working with it, composite keys had not been implemented yet and I found stumbling block after stumbling block.
But the product has evolved into quite a great tool. It's pretty feature complete compared to xml and provides all the benefits others have outlined already.
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.
Can anyone throw some light on tools that can be used with NHibernate and which perform the below mentioned tasks:
Generates the Mapping File
Generates the Entity Class
Generates the Configuration file
And also provide information whether these tools are open source or licensed.
Thanks
One tool I've used that did a decent job was CodeSmith. It looked at the existing database and created the entities, mappings and configuration file. However, this is only to be used as a starting point as there are many tweaks you'll likely want to do to make it more usable and better performing. Things such as when to lazy load vs. eager load, creating subclasses or components. This tool really just mimics the database structure in your entities which is not always the best way to represent in code.
This is a licensed solution but it includes a fully functional demo you can use to gen your files initially. After that, you'll most likely just enhance just as you would your database.
Another is MyGeneration. Same thing, it'll get you 75% of the way there in most cases.
Just be cautious as to which version of NHibernate these tools are producing. They may be using an older version which may have some obsolete code.
I really like Visual NHibernate (http://www.slyce.com/VisualNHibernate/).
Not free, but has a nice set of features, including the definition of templates for the entities, and generating both HBM.XML as well as Fluent NHibernate mappings.
A similar question with some answers you might find useful is already on SO.
NHibernate Generators
As mentioned in that question's answers, fluent NHibernate is a good option. It just went RTM. You can find more info at http://fluentnhibernate.org/
Check out LLBLGen Pro. It's got a competing ORM but can also act as a code generator for nhibernate. Very good for DB first work.