说服顽固的DBA将ORM用于大多数CRUD与存储过程,视图和函数

Question

说服顽固的DBA将ORM用于大多数CRUD与存储过程,视图和函数

And*_*mer 10 nhibernate orm entity-framework linq-to-sql

我已经使用NHibernate,LINQ to SQL和Entity Framework很长一段时间了.虽然我看到使用ORM来保持开发工作快速移动,代码简单,以及对象关系阻抗不匹配最小化的好处,但我仍然发现很难说服一个ORM强大的死硬SQL dba.从我的角度来看,ORM可以用于所有数据访问的至少90-95%,而在适当的程序或功能中可以完成那些非常繁琐的事情.我绝不是那个说我们必须在ORM中做所有事情的人!

问题:说服旧学校dba的一些更好的理由是,使用ORM并不是程序员曾经想到的绝对最糟糕的想法!

Answer 1

Gre*_*ech 12

如果你想说服他,首先你需要了解他使用ORM的问题.如果没有解决他所遇到的问题,那么给你一份通用福利清单是不太可能有帮助的.

然而,我对他的问题的第一个猜测是,它阻止他进行任何优化,因为你直接访问表,因此他没有后面的抽象层,所以如果一个表需要改变或(de)规范化然后如果不破坏你的申请,他就无法做到.

如果你想知道为什么DBA会这样,以及如何回应它,那么它跟他一样大致相同,并说他希望你把你班上的所有私人领域都公开,并且你如果不先问他就不能改变他们中的任何一个.想象一下他需要说服你这是一个好主意,然后对他使用相同的论点.

我喜欢你的观点.然而,我从未理解过的是为什么DBA和程序员不是"在同一个团队中".为什么我工作的大多数地方都有DBA和开发人员在他们的职责超过SOOO时彼此相互关联.在您进行优化的情况下 - 解决此问题的标准方法是ORM所有内容(99%？),确定优化需求,并在需要时将查询移植到proc.但在大多数情况下,我发现ORM生成了很棒的SQL! (3认同)
我们共同努力,广告根本没有摩擦.但你必须了解角色的差异.DBA负责保持数据库正常运行,备份和执行.如果由于表结构错误而需要更改数据库操作很慢,那么当它无法修复时谁得到了责任呢？DBA.但他无法做任何事情,因为人们直接访问桌子.这就是为什么他们中的许多人反对直接表访问的原因之一. (2认同)

Answer 2

Spe*_*ort 6

向他们解释为应用程序采取的每个操作创建存储过程在几个级别上是不可维护的.

如果架构发生更改,则很难跟踪受影响的所有存储过程.
不可能确保不创建多个存储过程来执行相同的操作,或者稍微改变现有存储过程将会产生严重后果.
在部署之后,很难确保应用程序和数据库是同步的.

动态SQL具有所有这些问题以及更多问题.

如果您使用数据库项目(例如VS2008中的数据库项目),那么它实际上会编译数据库,并会警告您由于架构更改而导致的任何错误(例如访问更改的列等),因此您的第1点无效.类似地,第2点无效,假设有人负责数据库并且不会让垃圾进入.并且3通过适当的自动部署而被否定.所以我真的不买这些论点. (3认同)
除非您的团队使用 SQL Server 以外的数据库，否则在 VS2008 中使用数据库项目不适合您。那么这些观点就很有意义了。 (2认同)

归档时间：	16 年，1 月前
查看次数：	2275 次
最近记录：	12 年，5 月前