As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would be interested in hearing op opinions from others regarding whether which they would choose (no 'neithers' please ;), and why.
What are the downsides to using fluent? (version dependancy maybe?)
Pros, Cons, Experiences etc.
Fluent NHIbernate sits on top of NHibernate, so its not really a choice between the two. If youre going to use NHibernate, CHOOSE to use Fluent NH on top of it to save yourself vast amounts of effort.
Fluent NHibernate is awesome, I wouldn't use NHibernate without it. You can fluently map all your entities (giving you compile time checking, and automated testing support) instead of having to maintain cumbersome xml files and remember their syntax/DTD.
It can also automatically map your entities based on default and/or your own custom conventions.
Just use it!
I would definitely say go with fluent-nhibernate. Just be aware it may not necessarily be as smooth a ride as you would hope.
Regarding version dependency
I have had a 'reverse' dependency issue when upgrading to a new version of FNH required me to upgrade to a new version of NH (2.0 to 2.1 I think). This was not a major issue for me.
I just recently (this morning) dropped NH 2.1.1 into the FNH 1.0 RTM (this is distributed with 2.1.0) without any dramas (yet).
Edit: Since writing this post FNH has matured substantially to the point where I do not think this is a real issue anymore
Mapping support - some mappings are not yet possible with fluent nhibernate. However, this is NOT a reason to avoid FNH as hybrid fluent-xml mappings allow you to fallback on traditional xml in the event of fluent being unable to map it (although this is only on per-class granularity). Examples of mappings:
Cannot yet map fields - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
Cannot map some times of dictionary http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - actually from what I gather this functionality exists but is not in the mainline yet.
Compound complexity factor. From the sounds of it you will be learning both FNH and NH at the same time. For the majority of fairly simple applications this is fine - infact FNH is often so good that you need to know fairly little about the hbm.xml mappings. But if you want to go do something reasonably complex, it will rarely work the first time round and you are left wondering if it is a PEBKAC, fluent or NH issue. More often than I'd hoped I ended up writing the traditional xml mappings (of course, you are doing this anyway, but it would have been preferable not to expend more effort than necessary fiddling with fluent first).
The advantage of using Fluent NHibernate together with NHibernate is that you get compile time errors if you have messed up your mapping, instead of runtime errors. You also get a much better experience when refactoring your code, since your mappings are kept up to date as you rename properties or whatever, instead of having to remember to manually modify you XML mapping files.
The biggest downside of Fluent NHibernate is that it is still in a quite early phase of its development, and there is quite a big risk of breaking changes as the development of the framework progresses.
Personally I havent really gotten much into fluent nhibernate as I am comfortable with the mapping files. using visual studio to create the mapping files is a breeze and you can set the schema for the xml file which gives you intellisense on the the mapping file. I agree that having compile-time syntax checking is an advantage to using fluent-nhibernate, but I struggle justifing learning the fluent API when I already am familiar with the XML mapping. Perhaps I should just get over my lethergy and learn it already... :-)
Fluent N-Hibernate is really a nice wrapper over NHibernate. To manage mapping in Fluent much better than xml mapping. Development become fast as you get on to Fluent...
Best if you use Entity Developer for creating entity and Database schema.
Related
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.
I am going to try using NHibernate, the reason I stayed away from NHibernate so far was the xml-mapping part. Now that (I found out) there is fluent nhibernate, looks like we don't need to do xml mapping.
But I am wondering if starting with some xml mapping, would be more helpful in learning and getting comfortable with NHibernate, or should I start using it with fluent for nhibernate?
cheers,
hazim
I had similar concerns when I started with nHibernate, but having taken the road of learning the mappings and then learning Fluent, I have to say I wish I had just started with Fluent.
My reasoning is that there was enough to digest just learning nHibernate and Fluent helps make nHibernate more simple. Having said that I agree with David M, you'll need to understand the mappings at some point.
This series was really useful when I was learning nHibernate.
HTH
I would actually recommend attacking NHib from a totally Fluent perspective right now - FNH has matured just enough to not drive you nuts with inconsistencies, there are a lot of decent learning aids out there (try and look at anything posted since Sep 2009 on at first), as well as a decently active user group.
I found this amazingly good and very recent video tutorial Vacation of Fluent NHibernate, conceptually based on the Summer of NHib series everyone else has here. Unfortunately the author just got a new job and hasn't yet completed the series, but I will be shocked if you don't find it incredibly approachable and useful as a learning tool all the same.
You also can fairly easily learn to generate the HBM maps, and reading them is way more useful IMO, and certainly less painful, than writing them at first.
Lastly, give yourself a break and don't expect to master any of this by the end of the week! If you spend some time with FNH first, you will know which areas of NHib you want to dig into eventually and feel less overwhelmed by it when you do.
Cheers,
Berryl
Suggest you get started with a simple database schema using Fluent's auto mapping, so you can get used to using NHibernate Sessions and SessionFactories properly. Then you can branch out. But at some point you will need to fall back on XML mapping, so it's worth looking at eventually.
For understanding what is going I'd recommend starting with XML Mapping files. When learning NHibernate I found hand building configuration files to be useful. That said after I was comfortable using fluent and the occasional mapping file builder has been great.
For learning NHibernate though it's targeted at a previous version the Summer of NHibernate is incredibly useful.
Start with the XML mappings. Fluent is getting closer to being feature complete, but the terminology it uses still diverges from the terminology within the XML mappings (which is what is used by most NHibernate tutorials / documentation). Once you've done a mapping or two, it really isn't that hard especially with intellisense support from the schema files.
Fluent NHibernate is great, but for a beginner I think it might lead to some confusion as you cross reference your mappings with online research.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
For a new project we are looking at NHibernate. We like it a lot overall, but one thing bothers us: it seems to be very resource consuming. Apparently NHibernate will load all the properties of an object even if you need only one of the properties. More over, it will do the same for the properties of child objects.
So we are weighing the pros and cons of NHibernate. What would you say they are, and if the upsides make up for the downsides?
Disadvantages:
It can take a while to get the hang of editing HBM files (although you could use Castle's ActiveRecord, which does session management, and let's you declare relationships with attributes, which it uses to generate HBM, since NH is underneath AR. Note: you don't have to use the AR pattern with Castle's AR).
It's probably going to run more queries to retrieve a particular graph of data than you would if you wrote it by hand
It's more difficult to make use of the power of the DB engine, since NH treats is like a dumb record store
Oracle support is not as good as other dialects.
Advantages
You can use Linq-to-NH, and use linq style queries against all the supported dialects.
You can use HQL instead of SQL
You can switch DBs venders with a couple lines in a config file
There are tools to generate your schema for you.
Support for versioning of instances
Advantages:
Second Level Caching
Creates the objects representing your data natively
Creates the SQL queries and avoids SQL injection
Lazy loading
Following foreign keys are easier.
DB translation (change the dialect)
The framework is well supported and is opensource
There are lots of tools that work with and generate code/mapping files for Hibernate
Disadvantages:
Can be slower than direct querying
Object initialization is slower than by hand
Initial configuration is a pain
Mapping is checked at runtime and that can be a pain to setup
It depends what you are doing. Hibernate is not the tool for bulk updating.
Here are some things that haven't been mentioned yet (sorry, it's not in pro/con format). These apply to situations where you will be creating a generic framework to do basic entity operations (so you have a reusable NHibernate library that you can use for other projects).
Setting it up is a real pain. Ours is stable now, but we started developing it a year ago.
Consider the type of applications you'll be developing (i.e., web forms or WinForms), because the session model you use in the generic framework may be different; or, you might want to develop a framework where you'd want to be able to plug in your own session management implementation. There are a lot of choices here.
If there is a chance of developing a highly concurrent application using the framework, design the concurrency model right from the start -- it could be very difficult to get it working properly later on.
If you use the NHibernate.Mapping.Attributes library, you don't have to deal with external XML mapping files. All you do is add metadata to your data object classes. This is really handy, intuitive, and easy to maintain.
That's all I've got for now. If I think of anything else, I'll add to my list.
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.