说服顽固的 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 和实体框架已经有一段时间了.虽然我看到了使用 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. 很难确保应用程序和数据库在部署后同步.

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

Dynamic SQL has all these issues and more.

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