Hello

I'm starting on a project and being new to ORM tools and almost new to databases in general.
I'm wondering if I should use a ORM tool or code generate something or simply do it manually myself.

I know this is not a specific NHibernate question, but I couldn't think of a better place to ask the question, to get convinced that a ORM tool is the way to go.

So if you have any good links or comments on the subject, I would be happy to know about them.

Thanks

ORM is not necessarily the way to go, but one good, cynical reason to use is because managers, in their infinite wisdom, like frameworks like Hibernate.

For them is appealing the concept that you do class->save (or something of the like) and the code gets magically persisted. Of course, all the jerry-rigging and infinite configuration problems you have to solve don't mean much to them.

In their minds, Hibernate means independence from the DBAs, and being bleeding edge and cool. The enthusiasm lasts between eight months and a year. then they give up and come back to reality.

In addition to what gozao_diaz said I would like to add that an ORM tool can save a lot of time but you should usually have to have the expertise in the team or it can be a failure point for a project. Some projects afford to train an expert in the their team. In addition, using an ORM tool requires your database to be normalized otherwise you will find yourself doing hacking code here and there. Some ORM tools like iBatis are more flexible with less normalized databases but they compromise other good features. Another point in determining whether you need an ORM tool is to ask your save how many use cases involve full cycle CRUD actions. If you find you are gonna need to mostly retrieve data instead of updating/inserting then many an ORM tool is not best suitable for you. Finally, most ORM tools are not so useful without caching. It's more like having a girlfriend but not seeing her. Therefore, if caching data can cause problems in your application design again you might not want to go for an ORM tool.



Farzad-

Yeah, Hibernate is like a cult, or an IMF economic policy, or the Iraq surge: when you fail using it, it is not its fault, it is your fault because you are not committed enough to it.

Another feature of your existing database that considerably helps in your transition to Hibernate, is to have those 32-char, single-column, randomly generated primary keys, in addition to your business keys.
Most things in Hibernate are still possible without them, but the complexity of the mappings grows considerably; also almost all documentation examples assume them.

I'll take it that you have some bad experiences with nHibernate?

Not at all, On the contrary, it is paying my bills.
I am just depicting it for what it is.

OK, so you are using it because you have and not because you want to?
Is that a common view on NHibernate is this forum, maybe ORM is not the way to go at all?!?

I'd say that it is worth it if you are willing to really devote yourself to learning it. NHibernate is hard to get used to and it can be a pain learning its quirks the hard way, but thats just how it is. Once you understand how it works, it makes lots of sense and all of a sudden it becomes much easier to use.

Just keep in mind that it is a system that must be understood in order to use it, so everybody on the team that will be interacting with it should spend a good amount of time learning it.

No one has mentioned the ability to separate your 'Domain Model' from your DataTables... I thought this was the main reason?

Really, the only true advantage, to me (as I currently know it) is that I'm writing lots of C# code where my business logic/formulas etc are isolated in my domain model - in code.
Which means, I can test it in isolation, without a database, and then when it comes to hitting the database, I'll use another layer of my application to run the queries.

Separation of concerns etc; anyone else with me here...?

In which case, I'm going to say that I don't agree at all with farzad's statement saying ... is way off the mark.

You use an ORM tool so you can keep your business logic in your code, and out of duplicated/unrepresentative/unmaintanable/waste-of-time SQL/stored-proc files. (I say 'waste' in the context of an ORM application where some queries using QBE could save writing 100 lines of SQL).

It becomes less useful, when you're doing very large/bulk updates, or when your domain model is not very complex or your application is just very small and simple. In those situations, I would consider skipping the use of ORM.

I see your point here but the reason I wont consider an ORM for only retrieving data is that it generates lots of sql statements which could be summarized in a single statement and one could leave the performance issues in hands of database engines (they are really good these days). ORM tools often offer features that enable you to use custom sqls but if that's all you have to do in your app you will eventually find it more complicated to do it the ORM way as compared to the native way (ADO I guess in a Microsoft world). One could argue second level caching eases this but I won't go for second level caching for only this reason. The reason behind this is that I usually prefer to have a single point of holding the truth, which in this case I prefer the database. Holding the truth in both a database and a (distributed) cache makes things tricky when it comes to scaling. Nevertheless, many applications might be of the foo-bar complexity and all I said above is void and irrelevant thereof. What do you think?



Farzad-