Search code examples
ormado.netcode-generation

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 classic ADO.Net?

Thank you!

Solution

  • 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.