Which DAL approach to take?

Question

ActiveRecord is too limiting normally. However, i'm in a difficult situation in terms of the views held by each member of the team in regards to using ORM's. We currently use a very basic ActiveRecord with regret I say is written mostly by hand with some basic generation of code. I would like to build a new DAL for us but avoiding the limitations of ActiveRecord, so DDD more so. The points however I am battling against are (both old skool developers and myself quite young):

Team Lead Developer

• Is in favour of stored procedures, but isn't consistant...some just get a table e.g. SELECT * FROM Company and some get SELECT C.*, O.OtherTableValue FROM Company C...(very frustrating)
• Doesn't really know the benefits of some of the latest ORM tools
• Won't commit to any tool as its "too restrictive" and if there are issues what do you do?

DBA

• Doesn't like dynamic SQL
• Doesn't like SELECT *

I'm not saying the above are off limits, its more convicing them otherwise. I belive we could massively improve our efficent with the use of an ORM but its very difficult to convince them otherwise. If I could give proof to some of these areas I might be able to convince them, even by implementing under the covers without them knowing initally and then seeing the benefits.

What advice can you give to help my situation? I believe many developers come across this and cannot choose which architecture they would like to use.

Answer 1

I think your Team Lead needs to either commit to consistency or spend some time on an ORM research project to make a recommendation to use. In other words, an inconsistent and set-in-ways Team Lead shouldn't be in that role.

Secondly, I tend to agree with your DBA for a number of reasons. As long as he/she is flexible enough to know that there are occasions where dynamic SQL will solve the problem much better.

For your specific situation I'd say ask your DBA to lay down the law that stored procs are to be used every time unless justification is provided on a case-by-case basis and enforce this through policy and monitoring. This will address the consistency issue. Perhaps then, with that policy in hand, an ORM looks more enticing than having to hand-code everything to the Team Lead.

Answer 2

The lead developer should listen to the DBA. "SELECT *" is bad. And from the bullet points about the lead developer it sounds like you've got a familiar uphill battle. Sometimes the path of least resistance in that situation is to implement something using an ORM (such as NHibernate) and schedule some kind of demonstration to the team.

Encourage their input, specially from the lead developer and the DBA and any other nay-sayers. They might have legitimate gripes that can actually be solved with the tool as you learn more about it. On the other hand, they might just be dead-set against it for no good logical reason. If that's the case, it's best to find that out because it could very well mean that there is no winning this argument against them, because they're not really debating.

Answer 3

What are their objections to using an ORM? If they are not just being obstinate and stubborn then if you know what specifically they object to you and address those concerns. Like the others I think your DBA is correct. But if he is concerned about SQL injection from dynamic sql, ORM's alleviate that issue somewhat. Select * should be grounds for a firing.

I'm of the mind where you should just use something, LINQ-to-SQL or subsonic or nhibernate on something small. Show that development can be faster and cleaner using an ORM.