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.
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 have just started using PetaPoco/NPoco in one of my projects and have to say that it rocks however, It seems that the library is not able to generate DDL and create a table based on the Poco. I know that OrmLite can do this.
Is there a way/workaround that can be used to for example decorate the poco and then based on the attributes DBMS specific table scripts are generated? e.g. Oracle, MSSql etc.
Thank you
No. PetaPoco seems (rightly) intent on staying small and lightweight, focusing on one thing (mapping between objects and IDb* concepts) and doing that well.
I could see this feature being semi-useful when running unit tests or very useful for prototyping, but IMO you want a DB migration manager to handle updates to your DB schema over time. Fluent Migrator is a good choice.
For me, it's about a separation of where we are (current PetaPoco / NPoco classes) and how we got here (migrations).
Not sure exactly what you are after, but we use NPoco.T4 to generate our models from DB. Maybe look into it. You can find it on Nuget.
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.
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.
As far as I can tell (correct me if I'm wrong), there are two main approaches to using Entity Framework:
Model First: start with a predefined database and let EF create the code for you.
Code First: write the code, and let EF create the database for you.
I have an existing database and I'd like to write the code myself. Is this "Code Only" approach supported? Does such an approach even make sense in the context of EF?
I disagree with most of the other answers. From what I've seen, the EF "Code First" technology is really just a way to define your model using conventions, annotations, or a fluent mapping definition, rather than an EDMX file. If you write your "Code First" files to mirror your database schema, there is no reason that Entity Framework would be unable to produce the appropriate queries and statements using LINQ to Entities.
For more information, see Scott Guthrie's post on Using EF "Code First" with an existing database.
Entity Framework Power Tools allows you to reverse engineer a database to generate code first like code (that won't re-generate your database). Then you can tweak it from there as you need.
I believe you have to decide what your system of reference is -- the code (Code First) or the database (Model First). If you have an existing database, then go with a Code First approach, it will be hard to keep your changes in synch without generating your model from your code, or your code from your model.
If you have an existing database, but want to extend your model beyond the generated code, you could implement partial classes to accomplish this.
If you want to manually map your EF4 code and your database, you could consider this approach. However, this eliminates some of the benefit of an ORM, which is to set up the mapping for you.
Well I guess you can't have your cake and eat it too in this case - there has to be one definite source on what your model is, it is either the database (DB first), which then generates matching code for you, or the code (Code first) which will then create a matching DB.
The Entity Framework team answered these questions on their blog:
http://blogs.msdn.com/b/adonet/archive/2011/03/07/when-is-code-first-not-code-first.aspx