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.
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.
I am trying to work out with ORM tool to move over to and have narrowed it down to two candidates.
nHibernate or LLBLGen Pro
Please can you guys give me pros and cons in using both these tools especially if you have experience in both. I am not really interested in any other tools but am wanting some heads up so I can decide which tool to spend time learning....
I already know that one is free and one isn't, I also know that nHibernate might take some learning....
Many thanks, Richard
I have used both. At first I was sold on nHibernate and refused to try anything else even though I knew about other options.
With LLBLGen Pro, I was skeptical, but soon saw the advantages as well. I have not totaly abandoned nHibernate. I will continue to keep int in my "box of tools". I have found LLBLGen useful in some cases especially when interacting with a database that already exists and you have no choice of re-designing it. It takes less than an hour (depending on size of database of course) to generate my LLBLGen Entity Objects from the database, as opposed to having to code all of it manually with nHibernate, AND do the mappings. nHibernate is missing a nice graphical interface to create the mappings. This fact becomes even more important when the database is massive with thousands of tables that you need to potentially access in your application.
Although LLBLGen is more of a Data Access Layer generator (And I am not normally a fan of DAL generators), it has a lot of features a "true ORM" tool would have. In my opinion it has the best of both worlds. Once you start working with it you start to realize that it is very flexible and extendable. One part I like a lot is that it is possible for me to create partial classes for the generated entity objects, where I can code in my business logic, as well as validation.
The code generation is templated so you have full control over the code it generates. With nHibernate I find myself writing some of the same kind of code over and over again. With LLBLGen I can generate it and get to focus on business logic and issues quicker.
For someone who is just starting to use ORM type tools, I really recommend to start with LLBLGen, because nHibernate can be overwhelming. And in the end you will have achieved the same result (More or less).
Edit #1: LLBLGen now also has 100% support for LINQ. (So if you like LINQ to SQL for that reason) further LLBLGen can support many databases, where LINQ to SQL is only for Microsoft SQL Database.
Edit #2:
According to Graviton you can use CodeSmith to do some of the code generating for you for nHibernate. That is really cool, but for a newcomer to ORM I would still recommend LLBLGen. To me that is adding more dependencies where LLBLGen has it all in one package. Also like I said before the learning curve is so much less steep and you will get the same benefits, which will also help you ease in to nHibernate if you ever decide to go there.
The major difference is that LLBLGen is a code generator, while NHibernate is a "true" ORM library.
LLBLGen advantages:
Easy to use model designer. Can import your existing database schema
Fully typed object model and query language
LLBLGen disadvantages:
You need the designer application to change your model
Not free
Can bloat your code because a lot of code is generated
NHibernate advantages:
No designer application needed. Only code
Widely used (based on the most popular Java ORM, Hibernate)
Very powerful for mapping any data model you can imagine
Open source
NHibernate disadvantages:
Hard to learn
Not as strongly typed as one would like (especially queries)
Of course, this is just my personal point of view...
I typed up a fairly long answer before realizing this was a somewhat old question. Oh well. It's still very relevant.
You have narrowed your list to the two best candidates for an ORM in the .NET world. I have limited experience with either, but I've read extensively about the pros and cons of both. They really serve somewhat different needs in different ways.
In the upcoming LLBLGen Pro 3.0, Frans Bouma has talked about adding features to generate NHibernate mappings. So, it's not even necessarily an either/or decision.
If you want to do "class first" design (as opposed to "database first" design), NHibernate is pretty much your best and only option right now (neither LLBLGen Pro nor Entity Framework support this mode, although it sounds like Entity Framework is improving it's support in the next version).
NHibernate and LLBLGen Pro both work hard to work well with legacy databases which you can not change and have to live with. That is their common strength. They both also work with Linq. They both also support some amount of graphical modeling, although LLBLGen Pro is far superior in this regard (ActiveWriter for NHibernate feels like the LinqToSql designer in Visual Studio, but it's not really as feature rich).
LLBLGen Pro has much stronger code generation abilities, but too much code generation can lead to compromised testability and maintainability (one small tweak can cause massive amounts of code to need retesting).
While NHibernate wants to help you work through fairly complex object/relational mapping scenarios like class inheritance, LLBLGen Pro is really just exposing your database as a data layer and business objects in a very quick way.
If you can purchase LLBLGen Pro and have some time, I would try both and see which one better meets your needs. Learning both ORMs is good for your resume in any case.
So, in the end, I would say it's situational. The cost of NHibernate and its lack of serious flaws make a pretty compelling case in the majority of situations.
The new version of LLBLGen Pro (3.0) allows you to generate code for NHibernate, so don't have to choose :). It also allows you to split up your entities into different domains.
I still prefer the LLBLGen pro runtime though, the LINQ interpreter is more complete and it has better change tracking of fields.
Unfortunately there's not many new features in the new LLBLGen Pro 3.0 runtime, as the creator first wanted to focus more on tooling than improving the existing framework.
I've used nHibernate, LLBLGen Pro, a custom data layer from my consulting company, the Enterprise Library, and LINQ. LLBLGen is by far my favorite and it allows writing one business layer that can talk to different types of databases using the same code providing database independence! Another incredible feature is it allows multiple connections to different databases. This is very useful when at a large company and one system is written in Sql Server and the other you have to interface with is in Oracle.
LLBLGen Pro is an amazing product backed up by Frans who is very active and works hard to fix issues. LLBLGen is like PhotoShop, it is an incredible tool and that can do amazing effects in the hands of someone who knows how to use. And like any tool that saves lots of time, it takes a week or two to learn how to use it, but will save months later on your project.
Not only did it speed up the DAL generation side of my app, it is also easy to create queries in the Business layer and send to the presentation layer. It made it easy to create an enterprise class application.
If one really wants to use nHibernate, start with LLBLGen Pro and generate the nHibernate code. If later on your department decides to switch from nHibernate to LINQ, you are covered. Want to switch from Sql Server to Oracle? This is possible and relatively easy with LLBLGen whereas with manually coded nHibernate code, you have to rewrite everything which is almost impossible to cost justify.
Frans was also available and answered some of my questions.
Don't forget one of the greatest plus point of Hibernate: HQL. With HQL, your SQL skill is not wasted. And Hibernate provides very nice, seamless support for native query as well.
If you have some weird, out-of-standard database, it's almost certain that you need your SQL skill at some point, and good luck with LLBL!
For me it boils down to database centric (LLBLGen Pro) vs. domain model centric (NHibernate).
Since I'm a DDD/OO guy, the choice has always been very easy for me, but I do see why LLBLGen Pro is popular.
We use LLBLGen at work, and it's reviled -- namely because we have multiple similar schemas, but you need to have a different DLL/Class library for each schema, meaning that it becomes annoying to write code that can target any schema.
Of course, that's an unusual environment, so it may not apply to you.
I need to collect some information about existing ORM solutions.
Please feel free to write about any programming language.
Can you tell about the best ORM framework you ever use and why is it better then others?
I used NHibernate and Entity Framework.
Current stable version of entity framework is very immature. It is too difficult, or impossible to perform common tasks. Testing your code is also difficult since you cannot really separate your entities from your data access classes. But it perfectly integrates with visual studio ide. Setting up is easy and updating all the models from database takes just a few seconds. Upcoming version of EF (4.0) will solve some of this problems.
NHibernate is quite powerful. It supports plain old clr objects, so you can work with simple entities. Configurations provide great control in great detail. Framework capabilities are satisfying and it has a large and active community and good documentation. Setting up and updating entities is a little difficult since you must use generators that looks up your database and generates entities and xml files. It may be tricky to find a generator or a template that exactly fits your needs. But once you set all things up, you will love it.
I found LINQ to SQL to be a pretty straight forward solution. The first time I used it, I'd say I had a basic ORM working within a few hours, and was creating LINQ queries with it.
Microsoft has an additional ORM (Entity Framework), which I've heard is more complex but may be useful for highly complex distributed applications with multiple data sources etc.
Overall I found LINQ to be an easy and fast to use ORM.
I have been looking at Telerik Open Access for last few months, in genernal this ORM has been a pain to work with, it was advertised as having extensive linq support but in reality many of the linq features you would normally expect dont work server side and are performed on the client. I also had problems using multiple conditions in a where clause, see my last question. Here are a few things that i found
No support for views
Unable to map more than one entity to the same table
Inheritance and Interface support requires you to make changes to you database schema
No visual designer like LINQ to SQL and Entity Framework
If you want to perform an insert any related entities must be fetched first
Rohan
LINQ2SQL was nice, EF makes sense, but is very complex and SQL Server oriented. NHibernate is special and Telerik OpenAccess (fully .NET / Visual Studio) got a broad set of functionality and professional support.
Since I know the product I can comment on Rohan's concerns:
Existing Views can be used and full Views support is coming up
Mapping more than one entity to the same table "works" for class hierarchies, limitation with reverse mapping exists
Inheritance and Interfacer support "do not require" changes to the the database schema, again limitation with reverse mapping exists though
Visual Designer will come, Forward and Reverse Mapping Wizards allow you already to do anything in an easy way
There is a workaround for the insert issue mentioned and it will be fixed generally
Check out the Telerik site to find happy customers and feel free to use the telerik forums and support resources for any question.
-Peter
Im new to OpenAccess ORM and we are using two products. Reporting and OpenAccess.
I think there are some features that people missed.
OpenAccess uses graphical designers while nHibernate still uses handwritten xml files
OpenAccess is not limited to SQl Server as EF4 and similiar frameworks
using it is easier and the forums are pretty helpful.
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster
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.
We've been using our own DAL for our projects in our company and for the passed 2 projects this has causing us problems. Because of this I want to study SubSonic and/or NHibernate. Is it better to study SubSonic first or NHibernate? What are the advantages/disadvantages? From what I have read from related questions here NHibernate is more complex compared to SubSonic so I want to start with the latter.
SubSonic is significantly easier than NHibernate, you can start working with it almost immediately (few screencasts and you're done). In NHibernate you need some more work to start up – XML config, Session handling and such stuff. So if you are new to ORM, learn SubSonic first, and then delve into NHibernate. Personally I think for small projects you can even happily end up with SubSonic :)
SubSonic is an Active Record ORM. If that is what you are looking for you should compare it with other active record ORM's such as Castle. Castle is built on top of nHibernate so your team can expand to full feature set if needed. AT this point your comparing apples to apples and it doesn't matter which one you start with.
If your not looking for an Active Record style ORM try starting with Fluid nHivernate to lower the learning curve a little.
I dont know a great deal about SubSonic but I recently took on the task of tooling up with NHibernate and found this book (probably the only one out there really) very useful
NHibernate is definately more complex, but with that complexity comes greater flexibility. Subsonic is great, but you should also be aware that it's very much an open source project and whilst it's currently stable, it doesn't have the active development community behind it that NHibernate does.
Another thing to be aware of is that subsonic is a sort of "code generator" where it will actually generate a bunch of stuff for you. NHibernate is an ORM in the very literal sense in that you map objects to your database. You can use code generators to generate the mappings for you, but it is a fundamentally different way of thinking about ORMs.
Personally, if you look at subsonic and find that it has everything you need, than I would look at that, or possibly even linq to sql, however if you find you're getting into more complex object problems, then maybe NHibernate is worth learning.
The answer depends on many different factors. If you learn nHibernate, you are opening yourself many doors of learning curves but they all pay off. Sub Sonic can get you up to speed but is based on code generation which means you have boundaries. With nHibernate, you define you own mapping. Infact with Fluent Interface nHibernate mapping, it's much more easier, simpler and faster to map the objects. There is a very active users group link text
Plus you have full flexibility of mapping. nHibernate could be a little hard to start with but it's totally worth learning. I myself have written 2 professional projects for my clients using nHibernate.