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
Related
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
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.
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.
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.