The best thing about being at a conference like BASTA is the great developers you get to meet. And the best thing about meeting with good developers is the great conversations that you have. Recently at DevExpress we decided it would be a good idea to broadcast some of these conversations to the wider DevExpress audience. To that end, I want to surface a conversation I had with a BASTA attendee today regarding ORM’s and why he would want to use one. In my view, a developer should consider using an ORM tool if he finds himself in one of the following scenarios:
You Work on a Team That Shares a DBA With Several Teams
Within software engineering there are always going to be more developers that DBAs, I mean has anyone here ever worked on a team where the DBAs outnumbered the devs? No, exactly. Of course this can cause problems.
Firstly, the DBA might be working on things for one of the other teams that he supports and the work for your team may have a lower priority. It may be high priority to you, but a low priority as far as the enterprise is concerned, and so you are just going to have to wait.
Secondly, even if the DBA is working on stuff for your team, the functionality that you require still might not be the top priority for him.
Here, an ORM tool can help you by abstracting the data access functionality away from you and taking over the services of a DBA. If your ORM tool supports the provider model, where there are specific providers for your RDBMS, then the SQL produced will be tailored to your specific needs and can be just as good as code created by your DBA. This can remove or reduce the bottleneck caused by the shared DBA.
You Work in a Small Developer Shop That Does Not Have a DBA
Without a DBA to help you out, the SQL side of object persistence can be off putting. You know that you know C# or VB or (insert language of choice), but when it comes to SQL, you can hack away sure, but you know your code is going to be sub-optimal at best. In this scenario, you can abstract that complexity away by using an ORM tool. The ORM tool can act as an RBDMS subject matter expert, allowing you to execute a “save” command, safe in the knowledge that the ORM vendor knows the best RDBMS specific method of achieving what you want.
You Want to Rationalize The Data Access Layers Used Within Your Organization
We all know this scenario. We were told at university that one of the main benefits of OO was code reuse, and yet in most organizations you can look around at a number of projects and see the Data Access Layer implemented in a slightly different way each time. Use an ORM tool to prevent this from happening. Instead of each architect going with his or her favourite pattern, simply use the ORM as the DAL and your code will be the same from project to project.
Your Code Needs to be RDBMS Portable
So you’ve written a great application, so good every enterprise is going to want to use it. It’s going to make you millions. The downside, apart from deciding how you are going to spend all that money, is the fact that each enterprise uses one of a dozen RDBMSs and of course they *must* have your app be compatible with the one they use. What a pain! Or at least it would be if you didn’t use an ORM. By using an ORM you abstract away the difference from RDBMS to RSBMS and moving from one to another can now be as simple as changing providers.
Now I’m not going to pretend that this list is exhaustive, but it contains the reasons that come most readily to my mind. I’m sure you can think of your own reasons for using an ORM tool – if so, feel free to add them in the comments, I’d be interested to read them (and to steal them to use the next time someone asks me why they should use an ORM tool). :-)
Update: Guys, I said post your reasons for using ORMs, not post your opinions of which ORM tools you like. Remember the ‘house rules’ no using our web / forums for advertising competitor products, it’s not polite. ;-)