What should I take into consideration if I need to choose between Fluent NHibernate and standard xml mapping files of NHibernate?
Can you compare the prominent differences that I should be aware of?
Several things and as mentioned this is possibly a duplicate question the main one I can think of is that you can change xml files without a code recompile but you cannot change mappings in fluent without recompiling something because they are by their nature compiled.
That said you can have a mappings assembly and then just patch that. Obviously whatever changes you make then need to be run through integration tests.
Aside from that Fluent Nhibernate can be confusing to NHibernate users because they mix some terms with their own so I always say you should start with XML file mappings until you totally understand whats going on then migrate to Fluent if you don't need to change the mappings without recompilation as it just reads better.
However don't forget you are then adding a layer of abstraction over the top with its own quirks which can make for interesting debugging.
Note: This is more of an opinion answer.
There's actually a 3rd option which you missed. NHibernate 3.2 shipped with it's own code mapping syntax.
http://nhforge.org/blogs/nhibernate/archive/2011/09/05/using-nh3-2-mapping-by-code-for-automatic-mapping.aspx
Personally I don't like the syntax, I'm a Fluent NHibernate fan and it works for me.
I think the only real thing to consider is what krystan already mentioned, which is the naming differences.
I personally threw in the towel with the XML mappings, and didn't pick NHibernate up again until Fluent NHibernate came out.
I don't believe you need to know anything about XML mappings, if you want to learn the XML mappings you can export Fluent mappings and look at them. But really the Fluent Mappings are dead simple.
Most problems from Fluent NHibernate steam from attempting to use Auto Mapping which maps a lot of assumptions, it's fine if you're planning on generating the DB schema, but if you've got an existing schema it's best to explicitly map them. I always explicitly write my maps tho.
Related
While we mostly use fluent configuration for our code-first POCOs, we have found it useful to use data annotations for things like the table name, PKs, etc. since it makes it easier for non-EF components that don't have a reference to the ObjectContext to interact with these entities.
In our experience, it seems that the two configuration styles can be mixed freely, with fluent configuration overriding DataAnnotations. Is this documented anywhere? Is there any risk to doing this mixed configuration?
We are currently using EF 4.3.1
You can use Data Annotation attributes and Fluent API at the same time. Entity Framework gives precedence to Fluent API over Data Annotations attributes.
I personally haven't ran into any issues with mixing the code first fluent api and data annotations. I also wondered if there would be any crossover pain and I can honestly say I have yet to find any. Here's a few references to case studies on the subject to ease your mind.
(Direct from the EF team)
http://msdn.microsoft.com/en-us/data/jj591583.aspx
(Part 1)
http://www.codeproject.com/Articles/476966/FluentplusAPIplusvsplusDataplusAnnotations-plusWor
I don't think it's a risk - as both things have equivalent counterparts for the most of it.
But, personally, when I run into some sort of issues around structuring my entities - first thing I do is to remove annotations if any - and move all to fluent.
Which over time led me to use pretty much straight fluent configuration (also freeing my my objects of any ties with the Db 'state of mind')...
IMO it is 'safer' but only in a way that you can do more and control
things exactly as you'd want them. Also helps with keeping things
consistent and in one place.
I am looking for an NHiberate mapping generator that can generate mapping by code rather than .xml or Fluent NHibernate.
I tried NHibernate Mapping Generator, but it has no validation. Thus, the existing mapping files might not 100% correct.
Devart Entity developer doesn't support this currently.
Any recommendations?
You could try nHibernate Designer from MindScape.
Well since you are asking for a suggestion, I can say by experience don't try to use a code generator. Such kind of approach fails when the project grow, you suddenly need to add some modifications and re-generating the entities would be a pain and so on. Try to read about ConventionalMapping. It is basically a strategy in building the mapping on the fly based on some conventions generally exists in a database table vs classes naming. I did this in past and with a little effort you will be able to concentrate just on the classes and completely forgot the mapping.
I'm having trouble choosing an appropriate data access framework, partly because I'm very picky with my preferences and mostly because I don't have much experience with most of them :-)
I need a framework that will allow me to easily map between the DB tables (SQL Server) and my entities, and that will handle the CRUD operations for me (for the most part).
I want my entities to reside in a separate assembly from my DAL.
I prefer using attributes for the mappings over external file like XML.
It doesn't have to be an ORM, and I want to code my entities myself.
I don't mind writing stored procedures.
The project's database won't be very big. Less than 50 tables.
I'd like some of my entities to correspond to an inner join of two tables - one for static data entered manually during development and the other with data filled during runtime - without using two entities that reference one another (the result of this join will be a single entity).
Entity Framework sounded perfect until I realized it doesn't support Enums (yet - and I can't wait for EF 5.0).
I want these entities to include Enums, and plan on using lookup tables for the enums + code generation for the enum to keep it synchronized with the database.
Linq-to-SQL seems like a good candidate, but I don't know if it copes well with my previous demands.
Using Enterprise Library 5.0 DAAB with it's RowMapper, and extending it's abilities to perform updates and inserts is also an option (but will require more coding on my part).
I plan on implementing the Repository Pattern.
How about NHibernate? Would it do? No experience there either.
I would be happy to hear all suggestions.. the more the merrier! Thanks in advance!
I think nHibernate is the way to go, although some of its main strengths (ORM, stored procedure generation, etc) are things you listed as non-requirements. Anyway, nHibernate will do everything you want it to do. Technically it does use xml mappings, but these can easily be auto-generated using fluent attribute mapping. I like this, as it IS done for you, but you get the customization too just in case you need it. Good luck!
I would like to set up a very simple demo application that includes LINQ over NHibernate. While I wait for an answer, I'm doing other tasks :)
I don't like HBM files at all
I need to set up a very simple database schema (3 tables)
I wouldn't exactly like to start from the DB. Maybe class model could be a better beginning
I haven't chosen target DB: probably MySQL
I know how to create a data model from HBM files. I know how to extract the data model from DB to .NET's Entity Framework but I believe my demo could be better done with NHibernate.
Can you suggest me a quick-start tutorial? I knew there was an old NH plugin based on annotations: that could be a suitable starting point...
Like Adam suggested, one option for you is to use FluentNHibernate and it's Auto mapping. Although, since your setup is really small, you could use the Fluent mapping as well.
Apart from the FluentNHibernate wiki, here are some resources:
Your very first NHibernate application by Gabriel Scheker
Getting Started With Fluent NHibernate and Auto Mapping in C# by Jason Mitchell
Another alternative with more recent version of NHibernate is mapping by code. This SO question has more than enough links, so I won't repeat them here.
As for attributes mapping, I suggest that you avoid it. They aren't used that much and you kind of poison your domain / POCO classes with data access concerns.
I have a databse with complicated relations. I need to know if is better for my project use Fluent NHIbernet or only NHibernate. I know than fluent is better for auto mapping etc. . But will i have some problems in future when I have complicated databes with realy complicated relaations. Have Fluent NHibernate some limitations. Have Fluent NHibernate some problems during configuration? Will be Fluent NHibernate slower as NHibernate?
someone correct me if im wrong, but I think under the hood fluent nhibernate creates the xml mapping files that get loaded into nhibernate.
You can configure fluent-nhibernate to handle both the ClassMap<> and the xml based .hbm.xml mapping files. If there are situations you run into that fluent-nhibernate cannot handle then you can drop back to the xml mapping files if needed. The advantage of the fluent-nhibernate mapping is that it is easier to refactor your POCO classes as you have compile time checking, where as the xml mappings you will only know if there is a problem at runtime.
The question is not constructive. The only difference between NH and FluentNH is XML binding definitions vs. in-code binding definitions. FluentNH only defines the schema, it does nothing to the ORM logic itself - it's still NHibernate.