Code generator vs ORM

I wrote a code generator which generates POCOs and repositories for a given SQL Server/CE database. Nothing fancy, only simple CRUD procedures using classic ADO.Net. My question is, why should I use an ORM like L2S/EF4 over custom code generator? Every 2 or 3 years Microsoft ships some new data access framework/technology and I know quite a few developers who can't always be in touch with the latest technologies, but every one of them knows the classic ADO.Net, how to modify the existing code and how to develop a new functionalities. Do ORM tools bring something which is a must nowdays, or I can stick with a cla开发者_StackOverflowssic ADO.Net?

Thank you!

I went to web programming, with its newer languages that lack proper data handling (which leads to the perceived need for ORM) at the same time I built my be-all-end-all code generator. Have never looked back.

One reason I would never consider an ORM is because I actually know how databases work, very well thank you. I don't something to try to make it look like I'm not using a Relational database, I want something to get me the power of the database with as little work as possible -- and that will never be an ORM because that is not what they are about.

In my experience a good dictionary-based generator is the truest D-R-Y programming (Don't repeat yourself), it can free me from the nit-and-pick of working with the DB and allow me to concentrate on what matters, getting good biz logic written on top of a solid table design.

EDIT: Two more points:

1) Going a non-ORM route is, if nothing else, lonely, inasmuch as ORM is so much the rage it is hard to find the people who never needed it and don't see the point. But let your technical judgement guide you.

2) A couple of years ago I wrote a blog entry, "Why I do not use ORM", which I will not link to because it was too inflammatory. After some time I tried again to capture the sense of why it is possible to look at ORM objectively and see no value, without being inflammatory, and that link is: http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html

Depends; do you like doing useless busywork with the database, or would you prefer to have it all generated?

Seriously though, for me, there is absolutely no question. Every knew project should start with an ORM, and for me, LLBLGen is the best. It's not free though. But it saves so much time in developing the data layer, and provides a nice structure to work with.

Really, it's a matter of deciding how you want to spend time. If you see value in working in the data layer, because of some series of reasons you can justify, when weighed against something like LLBLGen, then do it. But for me, I do not.

Of course, I agree with you, having to constantly change ORM's is not ideal. So I suggest you spend a bit of time (perhaps a few weeks) determining which one is the best for the style you like to develop in, and the way you structure your projects, and then go for it. Most of the main ways are very well supported these days anyway, so you couldn't be faulted to choosing one of them and standardising it.

One point in favor of an ORM is compile time checking. I'll use the entity framework as an example, since that's what I use as an ORM.

If you need to make a database schema change during development (remove a column, table, etc.), you update your model from the database and then compile. Everywhere that column or table was referenced now shows up as a compile time error, making it easy to catch bugs that would likely only be noticed at runtime with standard ado.net.

Another thing to think about is ad-hoc queries - what if you want to pull back just a few columns of data from a table? With generated code, you need to add a new query, class to fill with data, etc. With an ORM, you can do something like this, where an anonymous class is generated for you so you don't have to go through the busywork of creating one yourself.

Essentially, an ORM will handle all the edge cases that a home grown solution generally doesn't.

var q = from c in ctx.contact
        where c.contactId < 4
        select c.firstName, c.lastName;


foreach(var temp in q){
   string fullname = temp.firstName + " " + temp.LastName;
}

It really does depend on your project requirements and your development process. ORMs are packed with a lot of whiz and bring much joy to the table, but if your just shopping for a few distinct features, you might find the required mental/physical crud to be disappointing.

First thing you should know is that there are two kinds of ORMs: those that map an existing schema to application logic (you manage the schema) and those that map application logic to a schema (the ORM manages the schema). You should preferably avoid the first kind since they do not alleviate you of having to do/repeat considerable DBA work for each environment, i.e. you'll have to make sure all the devs are running an appropriate schema, in addition to making sure they're also running appropriate code. The second kind can completely abstract the fact your using an underlying database at all, so they allow you to focus on the application domain solely, which makes devs happy.

No DBA, no more local development efforts against an unmanageable remote DB instance, no more cross-RDBMS nuances, no more stored procedures, no more queries with hard-coded references, no more complex SQL migration queries.

So, ideally your ORM should:

• Automatically manage the DB schema for you
• Provide an in-place implementation of the Active record pattern
• Really be able to encapsulate all the business logic

Other nice sugars:

• Automatically manage data migrations (if you expect frequent ontology changes as opposed to no changes)
• Support for generating/importing fixtures

Keep in mind that you can start any project with an ORM like @Noon said, but you can't start every project without it nowdays. Ideally, ORMs are a fantastic fit for projects where you want the devs to be in full control or you need them to run private, local DB instances. Either way, it's a huge leap from the ass-backwards approach: make request to DBA, drink coffee until DB is updated, hope it happens within the week.

For simple CRUD and if objects represent a table code generators get you straight to your goal. ORMs become increasingly interesting, if

• you have complicated object relationships and need to traverse object references,
• need some caching mechanisms,
• need to deal with concurrent read/writes,
• need some versioning of table rows,
• have to deal with inheritance,
• ...

In short: If you need more just a plain mapping between a table and an object, then ORMs can be useful. Therefore you need to check out the feature list of the ORM and ask yourself if you need it.

There is an alternative something in between a code generator and an full blown ORM: Data mappers (like MyBatis formerly known as iBatis).