I am coming from an Entity Framework and LLBL background for my ORM tools.
I have been asked to build a new system based on NHibernate. I have never done so, so I am coming at it with fresh eyes.
What is the difference between mapping with Fluent NHibernate and "Mapping By Code" in NHibernate? Is there a preference?
Fluent NH
Fluent NHibernate offers an alternative to NHibernate's standard XML
mapping files. Rather than writing XML documents, you write mappings
in strongly typed C# code. This allows for easy refactoring, improved
readability and more concise code.
vs.
NH's new mapping by code
It is an XML-less mapping solution being an integral part of
NHibernate since 3.2, based on ConfORM library. Its API tries to
conform to XML naming and structure. There's a strong convention in
how the mapping methods are built. Its names are almost always equal
to XML elements names.
Some of it is preference, some of it is existing codebase. There was a time when NHibernate did not have any built in non-XML mapping options. There were a few solutions out there to fix this - e.g. confORM, Fluent NHibernate, and others I'm probably not aware of.
As of 3.2 I believe (perhaps 3.0) NHibernate now has "Mapping by Code". The advantage to this over Fluent NHibernate is that it doesn't require an additional library, and it is supported by the same team as NHibernate. On the other hand, Fluent NHibernate is a bit more mature (From what I've heard) and can support a broader set of mapping functions.
I also mentioned "existing codebase". Obviously, if you have a project that is already mapped with Fluent NHibernate, it would be best to continue on with it. If you're starting fresh, perhaps it is worth a try to use the built-in "Mapping By Code"
I know this post is old but, for anyone else interested on this matter, I would strongly recommend you to read this blog. It made it pretty clear to me and it even also gives you comparisons between the two approaches.
http://notherdev.blogspot.de/2012/01/nhibernates-mapping-by-code-first.html
Related
Do mapping attributes offer the same versatility as nhib hbm's do? Can you use them together with FNH to handle things FNH doesn't yet do as well as hbm's can?
Cheers,
Berryl
By mapping attributes, I don't mean hbm files; there are apparently attributes that come with NHib (or maybe NHib contrib these days) that you use to decorate your class & class properties. I'm guessing these pre-date FNH, but not sure.
I personally prefer to create the hbm.xml files myself. I've used Fluent, but I just like managing the nitty gritty myself for things like this. However I've not run into any mappings that I haven't been able to get working with Fluent though...
It is my understanding that Fluent nHibernate actually creates an hbm.xml file in the background based on your settings that is in turn used by nHibernate... so being that Fluent is itself creating the mappings, I would argue that just creating the hbm.xml manually would technically give you more flexibility and access to the nuance of the mapping file...
I think that there is a similar learning curve for both, so if you are going to bother learning Fluent that itself creates hbm.xml files, why not just learn how to create the damn hbm.xml files yourself in the first place and skip the middle man!
Unless you are doing MANY MANY projects in rapid succession, the act of actually mapping your database is only a fragment of the actual work you are doing on a particular project.
Max Schilling
The NHibernate attributes do pre-date FNH. Apart from a relatively small group of die-hard holdouts, I don't really know anyone that uses them. They're supported, but not exactly friendly. If you like attributes, the Castle ActiveRecord attributes are a much better implementation than the NHibernate core ones.
Fluent NHibernate can work with everything else. All it does is inject mappings into the NHibernate Configuration instance, so you can put whatever else in there you like. ActiveRecord is a bit more of a wide-reaching solution, so that may be an exception to this rule, it's been a while since I've used it.
I've never run into a situation that couldn't be handled by Fluent NHibernate, but maybe you're using an obscure attribute. Anything in particular you need to know is available?
We are using them in my business and I kinda like them.
I think it is really neat writing the mapping directly in the class definition (I know - to each one his own).
I agree with most the comments here, Hibernate gives you the freedom of choice on how to implement the maps for the objects.
I prefer not to use attributes on my classes for NHibernate, as now my classes now have another dependancy which they should not know of.
What happens if you want to change your datasouce to a OODB or just a file. The classes will have redundant mapping code(the attributes). in this case it could be said, its cleaner to store the mapping in the data/infrastructure layer with the repository implementation (assumed useage of the repository pattern)
I also agree, each to they own :)
I'm trying to understand where NHibernate 3 stands in relation to Hibernate 3 with respect to attributes vs annotation. I've been on several Java projects where we used Hibernate 3 annotations for mapping. It is quite elegant as
the entitites are clearly documented where the code lives
easier to debug when stepping through the debugger...
you don't have to go open a separate file out of context
less artifacts to manage
compile time checking
intellisense = fewer typos
no need to install/learn a separate 3rd party component (e.g. FNH)
the Hibernate team invested in making annotations easy to use and integral
Not sure I buy the "what if you have to change datasources" or the "separation of concerns" arguments. In practice, those arguments are looking at the "20%" (or less) that either won't occur, or have marginal impact if they do - the benefits are far greater IMHO.
With that said, what is not clear to me is whether the NHibernate team has invested enough in making the attributes robust enough to warrant use, or would I be better off moving to EF4.x to get the same benefits... those are the answers I was hoping for from this post.
Are there any good alternative to NHibernate's xml mappings?
I have seen Fluent. All I look for is high maintainability.
UPDATE : I would like to know the performance issues related with using fluent because I guess it is going to create xml mappings from the class (which can be time consuming - my guess)
Thanks
Fluent, but then again I would say that.
There's a minor performance impact by using it, but it's got nothing to do with XML generation*. NHibernate has a start-up time of it's own, and fluent only adds a fraction onto that; it's not even worth thinking about unless you're throwing around thousands of mappings (and more specifically, assemblies).
* Fluent's performance impact is actually from calling Assembly.GetTypes() to find any mappings in your assemblies.
I have seen Fluent..
Then go for it!
Fluent is a great alternative. I use NHibernate with Fluent, and it has been working out very well. I find the Fluent Configuration being much more maintainable and nicer than default NHibernate configuration.
Check out the Fluent Wiki - great documentation and a good starting point.
Regarding your edit I can't give you any concrete answers, but I have never seen any performance issues using Fluent myself. I assume NHibernate alone would be slightly faster on startup, but once the mappings are made there should be no difference. Also note that the performance in writing the code will be better due to the simplicity Fluent offers ahead of NHibernate configuration.
I used Linq To XSD to generate a class library from the mapping file xsd definition which gives you statically typed mappings, which you can write helpers and conventions for. The nice thing about it is that the syntax looks very similar to a normal hbm.xml file, while I haven't had the time to learn how to do each mapping in Fluent.
Other options are ActiveRecord and NHibernate.Mapping.Attributes
As the title says, I'm wondering if I should avoid using fluent nhibernate for production code, or if it's mature enough to just "dive in"? :)
The FluentNHibernate API has not yet stabilized and there have not yet been any releases.
However, FluentNHibernate is one of those special cases where there is no long-running behavior, only input leading to output. So you can certainly build a fluent mapping between your domain model and your database, inspect the resulting Configuration, and determine whether that Configuration is correct.
I just want to do a quick poll to see if Fluent Nhibernate is well received or if it is having lot of issues. I like Nhibernate but I definitely see the problem with xml to do mapping.
So, I am looking forward to community members for some insight and help me pick one over the other.
I am not considering either linq2sql or entity framework at this time.
I like Fluent NHibernate and I think it's mature enough if you are going to start a new project. Using it on a new project should allow the Fluent NHibernate project to continue to mature as yours progresses. There is a possibility for breaking changes (as happened recently with the convention mappings) but you should be able to deal with those. I've had a few issues with the mappings but the project is pretty responsive to bug reports and has mostly worked as expected.
The mapping options are:
Xml mappings - Standard of NHibernate. The maintenance headaches are well known but the advantage is that you have access to all of the configuration options provided by NHibernate. There are a few less-used configuration options are still being added to Fluent (at least last time I paid attention). So, if you are anticipating some crazy mappings, you may want to consider this option.
Standard Mapping - Provided by Fluent. You can create the mappings through code and is much better for refactoring and authoring. Not much to say about it, in my experience, other then that it works well and is a big improvement on the xml option.
Auto Mapping - Provided by Fluent. Allows you to map object properties by convention and it attempts to create the mappings automatically. It's a good idea but I think it still has some maturing to do. I'm currently using this mapping method and it works fine but I have ended up writing a large number of conventions and specifying the object relationships that it doesn't feel like it's saved much effort from the standard mappings.
Fluent NHibernate also provides nice test helpers for testing your mappings and some configuration APIs that can make it easier to configure NHibernate. Overall, it's a good project and it provides some nice additional functionality to NHibernate.
edit:
One additional thing to note: If you start off with Fluent NHibernate and decide it isn't going to work for your scenario, you can easily migrate back to the xml mappings. Fluent NHibernate allows you to export the mappings it creates and you can use those exports to not lose whatever mapping work you've already done.
One of the best advantages of using Fluent Nhibernate over vanilla NH is nice integration testing with PersistenceSpecification<T>:
[Test]
public void TestProductSave()
{
new PersistenceSpecification<Product>()
.CheckProperty(x => x.ProductName, "Wax")
.CheckProperty(x => x.Price, 20)
.VerifyTheMappings();
}
I've been using fluent on a new project of mine. The only minor bump I've hit so far is that it doesn't play so well with Castle Windsor out of the box, but it was quite easy to extend Windsor to do the job. Other than that I've been loving it. It's much more concise than the XML mappings.
The nice thing about fluent is that it isn't an all or nothing investment. You can write most of your mappings in fluent and if you find any issues you can map those classes in the standard XML mapping until the fluent issues are resolved.
Like any good answer, it depends.
I didn't get as much mileage out of the automapping features as I would have wanted to. I often have to work with preexisting databases.
I already had several projects using NHibernate under my belt, so using the hbm mapping wasn't difficult. After I figured out how to include in the hbm schema, it was much easier.
The one real advantage I gained from having fluent-nhibernate is being able to refactor my domain classes and have my mappings automatically change. I didn't really notice that much of a speed increase in writing the mappings.
Like anything, YMMV.
I am using FNH for a new project. What I like the best is the ability to generate and build the database directly from the entity classes.
I have had to write a few conventions for the properties but I'd rather that then maintain more than one list for each class.
I'm interested in moving some NHibernate configurations/mappings into the code to help with some maintenance issues. Can anyone provide any advice/pros/cons/comparisons of Fluent NHibernate vs. NHibernate.Mapping.Attributes?
I have some experience with Java Hibernate annotations, which I liked, but I'm curious if the NHibernate attributes are comparable, and whether Fluent provides any major upsides/downsides that should be considered.
I don't think anybody has done any outright comparisons. It falls down to how comfortable you are with decorating your entities with attributes. Fluent NHibernate is aimed at letting you use NHibernate with a completely unpolluted model, while attributes require you to alter your entities; this is a persistence concern leaking into your domain. Whether that's a problem for you is whether you should choose attributes or not.
Fluent NHibernate also throws a few more things to the table than just mappings. There's also the auto mappings which allow you to automatically map your domain. There's the conventions support which allow you to greatly reduce repetition in your design. I won't repeat everything, but you can read more on the Fluent NHibernate wiki.
NHibernate now supports JPA (called NPersistence or NPA for the .NET platform) including JPA annotations.
It is the best way to map your entities and have your code portable for other vendors as well.
check it out:
www.npersistence.com