采用哪种数据访问层(DAL)方法?

3
ActiveRecord通常限制太多了。然而,就使用ORM的观点而言,我遇到了困难。我们目前使用一个非常基本的ActiveRecord,很遗憾地说,它大部分是手写的,并且只有一些基本的代码生成。我想为我们构建一个新的DAL,但避免ActiveRecord的限制,更多地采用DDD。但我所面临的问题是(既老派的开发人员,又年轻的我自己):
Team Lead Developer:
- 倾向于存储过程,但不一致...有些只获取一个表,例如SELECT * FROM Company,而有些则获取SELECT C.*,O.OtherTableValue FROM Company C...(非常令人沮丧) - 不知道一些最新的ORM工具的好处 - 不会承诺任何工具,因为它们“太受限制了”,如果有问题怎么办?
DBA:
- 不喜欢动态SQL - 不喜欢SELECT *
我并不是说上述都是禁区,而是更加说服他们。我相信,通过使用ORM,我们可以大大提高效率,但很难说服他们。如果我能在某些领域提供证据,我可能会说服他们,即使在他们不知情的情况下,在幕后实施并看到好处。
您能给出什么建议以帮助我的情况吗?我相信许多开发人员都会遇到这种情况,无法选择他们想要使用的架构。
3个回答

2
我认为你们的团队领导需要在一致性方面做出承诺,或者花些时间研究ORM并提出使用建议。换句话说,不一致和固执己见的团队领导不应该担任这个角色。
其次,出于许多原因,我倾向于支持你的数据库管理员。只要他/她足够灵活,知道动态SQL在某些情况下会更好地解决问题。
对于你们的具体情况,我建议你询问你的数据库管理员制定规定,要求每次都使用存储过程,除非提供案例来证明有合理理由不使用,并通过政策和监控来强制执行。这将解决一致性问题。也许有了这个规定,使用ORM比手工编写代码更具吸引力。

关于团队领导 - 他不会改变自己的方式,他对工作没有真正的兴趣来改善事情...更多的是“那就行了”。我认为他不应该做这份工作,但这不是我的决定,所以我必须将就。关于数据库管理员,他并不真正理解应用程序带来的问题,因为数据库是他的背景,我认为他学到了一定程度,但之后就没有再学习新的变化,例如动态SQL现在并不总是不好。 - user203538
我建议你阅读《死亡进程》这本书。可能会对你的情况有所帮助。 - Jesse C. Slicer
看起来像是一个新的数据访问层或者另一个任务。 - user203538

1
首席开发人员应该听取数据库管理员的建议。"SELECT *"是不好的选择。从关于首席开发人员的重点中可以看出,你们正在经历一场艰辛的战斗。在这种情况下,有时候最简单的方法就是使用ORM(例如NHibernate)来实现某些功能,并安排一些演示给团队观看。
鼓励他们提供意见,特别是来自首席开发人员、数据库管理员和其他否定者的意见。他们可能有合理的抱怨,随着您更多地了解该工具,这些问题可能会得到解决。另一方面,他们可能没有充分的逻辑依据,完全反对该工具。如果情况是这样的话,最好弄清楚,因为这很可能意味着你无法在他们身上赢得争论,因为他们并没有真正的辩论。

很明显这并不是一个真正的辩论...就像我之前评论的那样,他们学习了一些东西,但是5-10年过去了,他们认为仍然是最好的方法。我认为唯一能让我获胜并改进事情的方法就是推出自己的数据访问层(DAL),但问题是从何处开始,这是个非常大的任务。我知道有人说不要这样做,但我真的认为我没有太多选择 :( - user203538

1

他们对使用ORM有什么反对意见?如果他们不是固执己见并且顽固不化,那么如果您知道他们具体反对什么,就可以解决这些问题。与其他人一样,我认为您的DBA是正确的。但是,如果他担心动态SQL的SQL注入问题,ORM在某种程度上可以缓解这个问题。选择所有列应该成为开除的理由。

我的想法是,在小型项目中应该使用LINQ-to-SQL、SubSonic或NHibernate等对象关系映射(ORM)框架。展示使用ORM可以更快速、更干净地进行开发。


关于创建一个新的数据访问层(DAL),最好以哪个ORM为基础呢?如果我已经创建了它,那么他会使用它,所以只需要一个起点,调整并借鉴其他ORM的一些思想。Subsonic似乎是一个简单的代码库...你有什么想法吗? - user203538

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接