+972 52-548-6969
On the sad state of NHibernate code generation
time to read 1 min | 182 words
I wanted to generate NHibernate mapping & objects from the Northwind schema, to be able to run the same queries as the Linq samples. I evaluated several MyGeneration templates as well as a commerical product (GenWise). None of them had an output that I would dim acceptable.
What od I mean by that?
- Singularizing the table names when creating an entity.
- Properties names that follow the .NET Naming Guidelines.
- Able to generate many to one <set>
I like code generation in general, but I know that there are many people who swear by it. And come on, it is Northwind, the database equivalent of Hello World. Are there any reasonable code generation tools for NHibernate?
If there isn't, I am willing to trade, a Linq implementation for a code generator that can handle the Northwind database.
Comments
If I implement the following, does that count?
Since ActiveRecord generate hbm.xml, before outputting code in ActiveWriter I run generated code through AR in memory to get hbm.xml. I can write it out to a file. Classes will be there, only they are also decorated with AR attributes.
If that doesn't count, I fell like I'm still close to generating what you want. <class name=... instead of [ActiveRecord], huh?
Cleaning the source from [ActiveRecord] attributes isn't a hassle, although I assume that you can make a check in the code and basically generate it twice, right?
Once with attributes, and then generate the HBM from that.
And a second time without the attributes
Gokhan, that would be excellent.
The thing with 'Singularizing the table names when creating an entity', there's a problem with consistency: it's not always to drop the 's' from the end.
LLBLGen Pro's designer has a lot of features to make names obey a given guideline, be it your own or the MS one, with plugins you can modify the names or whatever you want.
Some people have asked me in the past to produce nhibernate templates, and as all meta-data is available, I can generate mapping files with all info but also entity classes and other additional classes. The thing is that we're currently undecided if this is useful to us, as it might show we don't trust our own o/r core library.
Though if you want me to create the templates for you, Ayende, drop me a note. :)
Singularzing the table names:
https://svn.castleproject.org/svn/castle/trunk/ActiveRecord/Castle.ActiveRecord/Framework/Internal/Inflector.cs
I can understand the business reasons for not wanting to support NH as well.
I actually am more interested in a tool to create those templates than the templates themselves.
Consider this as a challenge to the NHibernate community.
Thanks for offering.
Singularization is language dependent. In dutch other rules apply and I'm sure in Hebrew other rules apply. This makes it very complicated.
Template creation is actually not that exiting. A template editor is enough, we have one of course. The thing what's more important IMHO is the templates, and the framework to use these templates in, like a task based engine and task performer assemblies which perform the tasks for you, so you can generate a lot of different classes at the same time. (like we have).
Actually, what we sell is the license for the designer/code generator engine, so we probably will consider the NHibernate templates, as it will make our work more complete as we currently don't have POCO support.
I really don't want to get into this. And I mean really not.
I have to work with databases where the tables are called QWTWQ and there is a look up table somewhere that translate this value to Hebrew table name.
And I have to work with databases where they transcript-ed from Hebrew. In both cases, it is a mess, annoying and plain obfuscated.
I am not sure if it is because Hebrew is not using the Latin alphabet (btw, alphabet is a Hebrew term, for what it worth), but I consider code to be a WTF just by the nature it exists.
Yes, all I want is to support English. I would explicitly not want support for Hebrew.
if(lang == "he-IL")
throw new NotSupportedException("Learn English - תלמד אנגלית");
Heh :) I agree that everyone should 'just do it right', however that's not the case in general, there are large groups of people who simply have to work with garbage stuff or create the garbage. If you want solid tooling which appeals to a lot of people, you unfortunately have to consider things like tablenames/fieldnames in other languages than english. And for example on DB2, people are often using abbreviations because of the tablename length limit which existed for a long time. In English it's also not 100% standarized though. There are plural names which can't be singularized using a simple routine. Perhaps these can be pulled from a table, I'm not sure.
The QWTWQ table name?
That is from a DB2 database.
I am sad to say that this isn't the worse that I have seen.
http://sourceforge.net/projects/nhibernateaddin
Interesting... worth a look
That add-in makes the same mistake as the Linq to Sql/Entities designers: the whole model has to be placed on a single canvas. You can't do that with a model with several hundred entities.
Frans,
I would make the argument that if you have several hundred entities, they should be broken to discrete modules, not used all at once.
Customers
Orders
Storage
Etc,
I just wrote a post about a good reason why LLBLGen Pro should start to support NHibernate (and ActiveRecord and Gentle.Net) code generation:
http://ale.riolo.co.uk/2007/03/llblgen-pro-to-support-nh-gn-ar-1.html
Frans,
actually the whole model doesnt need to be placed on a single canvas, that was one of the features I put at the top of the list when I designed the NHibernate Addin. You can create multiple diagrams in a single project, and tables will be 'referenced' from one diagram to another automatically.
Or, if you have referenced another project or assembly that contains a diagram, the plugin attempts to link to those types instead of recreating them in the new diagram.
I personally hate not being able to divide your diagrams by domain (or purely for designer rendering performance), but have them act as one unified model...
Thats what you're talking about isnt it?
Comment preview