说服顽固的DBA将ORM用于大多数CRUD与存储过程，视图和函数 [英] Convincing a die hard DBA to use an ORM for the majority of CRUD vs Stored Procedures, View, and Functions

问题描述

我已经使用NHibernate，LINQ to SQL和Entity Framework已有一段时间了.而且，尽管我看到了使用ORM来保持开发工作快速进行的好处，但代码却很简单，并且对象关系阻抗不匹配到最小，我仍然很难说服顽固的SQL dba ORM的优势.从我的角度来看，ORM至少可用于您所有数据访问的90-95％，而那些真正繁琐的事情需要在适当的过程或函数中完成.我绝不是说我们必须在ORM中做所有事情的人！

I have been working with NHibernate, LINQ to SQL, and Entity Framework for quite some time. And while I see the benefits to using an ORM to keep the development effort moving quickly, the code simple, and the object relational impedance mismatch to a minimum, I still find it very difficult to convince a die hard SQL dba of an ORM's strengths. From my point of view an ORM can be used for at least 90-95% of all of your data access leaving those really hairy things to be done in procedures or functions where appropriate. I am by no means the guy that says we must do everything in the ORM!

问题:有什么更好的论据可以说服一个老式的dba:使用ORM并不是程序员曾经想到的绝对最糟糕的主意！

Question: What are some of the better arguments for convincing an old school dba that the use of an ORM is not the absolute worst idea ever conceived by a programmer!

推荐答案

向他们解释说，为应用程序执行的每个操作创建存储过程在多个级别上都是不可维护的.

Explain to them that creating a stored procedure for every action taken by an application is unmaintainable on several levels.

1. 如果架构更改，则很难 追踪所有存储的 受影响的程序.
2. 不可能确保多个 没有创建存储过程来 做同样的事情，或者稍微做一下 改变现有的存储 程序将会很严重 后果.
3. 很难确保 应用程序和数据库都在 部署后进行同步.

1. If the schema changes it's difficult to track down all the stored procedures that are affected.
2. It's impossible ensure that multiple stored procedures aren't created to do the same thing, or if slightly altering an existing stored procedure is going to have serious ramifications.
3. It's difficult to make sure that the application and database are in sync after a deploy.

动态SQL具有所有这些问题，甚至更多.

Dynamic SQL has all these issues and more.

这篇关于说服顽固的DBA将ORM用于大多数CRUD与存储过程，视图和函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！