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.
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
I use NHibernate. I need to decide how validate domain entities. What do you recommend? Are there any troubles if use NHibernate with Fluent Validation?
Of the O/RM tools I know, NHibernate has the smallest footprint in the C# code of domain classes. It almost allows working with POCO's while being totally oblivious of dependencies. That is exactly what FluentValidation allows too. So it seems like a happy marriage to me.
But I wouldn't dare recommend or advise against any validation tool or framework without knowing more of your context. There are many candidates and they would work with NHibernate as well. Data access and validation are two different concerns that should (and can) be separated from one another.
Fluent validation is really good for user input validation, and can be used for simple business rules. But it has no integration with NHibernate. That means that nothing would prevent NHibernate from saving not valid entity except your custom code.
On other hand there is a NHibernate validator project. It has an integration with nhibernate, and it won't let you to save not valid entity.
Generally your domain shouldn't know about your ORM. It should be kept in isolation. So my answer is:
I Can not see any issue with NH and FNH Validation, but keep domain in isolation as much as possible.
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.
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