Home/ Questions/Q 988413
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T05:38:01+00:00

ActiveRecord is too limiting normally. However, i’m in a difficult situation in terms of

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0