如何鼓励自己改用ORM？答案

【问题标题】：How to encourage myself to switch to ORM?如何鼓励自己改用ORM？
【发布时间】：2011-04-10 13:27:17
【问题描述】：

我正在处理我的队友 (.NET/Oracle) 的遗留项目。该项目尚未完成，正在建设中，远离生产。他遵循一种“传统方式”来访问数据，即创建存储过程，然后使用数据库驱动程序调用它们。我想遵循一种“现代方式”来访问数据：使用 ORM 来抽象和访问数据。就时间和金钱而言，转换不会花费太多。问题是，他比我更有经验，而且他有点讨厌 ORM（他没有解释原因，但他说这很令人困惑）。我现在一个人呆着，但我没有受到足够的鼓励来切换到 ORM。

那么，我应该切换到 ORM 还是不切换到 ORM？如果是，请鼓励我。

编辑：我不知道为什么有人需要关闭这个问题。我没有受到足够的鼓励，因为我不确定哪种方式更好。你可以说服我，ORM 让我开发得更快，错误更少，或者存储过程更快，......无论如何。我想问你，恕我直言，有经验的程序员（比我，还有我的队友）。我的队友得到了使用存储过程的理由，许多程序员都有自己的理由。我需要知道他们为什么这么认为（存储过程相当好，或者他们只是想使用类似的东西，等等......）

非常感谢。

【问题讨论】：

标签： .net database oracle stored-procedures orm

【解决方案1】：

在我看来，SPROCS 从来都不是一个好主意。

PL/SQL 很少，而且通常永远不会自动测试。当你实现它但没有单元测试时它可能会工作，你怎么能确定它在没有回归测试的情况下将来会继续工作。我觉得每个人都应该采用的一种做法是 TDD。有了纪律，TDD 将不允许编写没有自动测试每个构建以解决回归问题的代码。不要误会我的意思，我不建议你去 TDD 你的 PL/SQL（我知道这在技术上是可行的）。我建议您将代码保存在代码库中。
PL/SQL 不利于简单的调试。可以单步执行您的 SPROCS，但不能通过传统的应用程序调试方式（尤其是 .NET 到 Oracle；也许 .NET 到 MS SqlServer）。
使用特定于数据库引擎的逻辑不仅会将您的应用程序绑定到该数据库供应商，还绑定到该版本的数据库，并且通常绑定到该版本的数据库驱动程序。我参与了一个使用 .NET 和 MS SqlServer 的项目，它最初是用许多 SPROCS 实现的。客户最终表示，他们不愿意支付 SqlServer 许可费用，并希望切换到开源数据库引擎（具体为 MySQL）。我们无法轻松满足这一要求，而且当有如此多的框架可以轻松地轻松切换数据库引擎时，这是不可接受的。

话虽如此，已经指出了数据库逻辑的好处，例如优化性能、充分利用现有 Oracle 许可以及切换现有应用程序的复杂性。除了 ORM 之外，我永远不会用任何东西开始一个新项目，但迁移现有应用程序并非易事。最后，您必须权衡利弊并做出明智的决定，以证明投资回报是合理的。

【讨论】：

我为我的观点提供了有效的论据，我希望反对者也能这样做。让你想知道他们是否有任何...

【解决方案2】：

此时切换到 ORM 是一个被宠坏的孩子的行为，如果你在没有我事先同意的情况下在我的团队中这样做，我会解雇你。使用存储过程有很多正当理由，包括不允许在表级别访问数据，这对于金融系统来说至关重要。想要学习其他工具而想使用它是幼稚且不专业的。

ORMS 对于许多复杂的问题并不好，当事情变得复杂时，它们通常会创建性能不佳的代码。存储的过程可以更容易地进行性能调整，这很关键。存储过程为您的数据提供了更好的安全性，因为您可以限制对表的直接访问，并且只允许用户执行 porc 定义的任务，从而减少欺诈的可能性。如果所有查询都在存储过程中，那么重构数据库也容易得多。对查询的更改也更容易应用，将存储的 proc 更改加载到 prod 比重新编译和重新加载整个应用程序要容易得多。

讨论要使用的工具的时间是在项目开始时而不是在中间。一些在 ORM 中完成，一些在存储 porcs 中完成的项目将成为维护的噩梦。

【讨论】：

【解决方案3】：

自言自语：

你的队友更有经验
你必须来这里讨论论据
您的队友已经有了可行的解决方案
您的最后期限迫在眉睫

除了技术上的争论，我个人不敢根据这些事实开始讨论改变数据访问层。与您的同事讨论在新项目中使用 ORM。通过开始讨论已经采取的基本分歧，不要在正在运行的项目中感到头疼。

【讨论】：

+1 @Robert：我同意你的大多数 cmets，但原则上不同意你的最后一句话——如果已经做出可能被严重误导的决定，那么它仍然是值得讨论。（当然，在这种情况下，这个决定似乎是正确的。）
如果以前的决定和假设没有定期讨论，我们的行业将不会熟练地发展。永远不要害怕质疑一切。否则，创新就无法发生，事情就会停滞不前。
@马克。同意，这不是一般性陈述（主要），而是提到第三点：有一个可行的解决方案。
@Gweebz 同意，但我的观点是“一切都有时间”。事实上，我鼓励他在一个新项目中开始这个讨论。没有一个“迫在眉睫的最后期限”。

【解决方案4】：

以下是不切换的三个原因：

Oracle PL/SQL 是一种完整的编程语言。这不仅仅是一些冻结的 SQL 语句和一些条件编程。所以很可能PL/SQL层包含了在ORM中不容易实现的逻辑。
众所周知，Oracle 数据库许可证非常昂贵。最大化它们的投资回报率的最佳方法是利用内置功能。使用 ORM 工具更难做到这一点，有时完全不可能。
您将您的应用程序描述为“旧版”，这表明它正在生产中。如果是这样，那么更改数据访问架构将是一种严重的放纵。您和您的同事将花费大量时间编写代码，更不用说对整个应用程序进行回归测试了，对您的用户没有明显的好处。

【讨论】：

@APC：我忘了说，旧版应用程序还没有完成，它正在建设中，当然，还没有投入生产。所以如果我切换到 ORM，它不会那么贵
你怎么能在构建一个新的“遗留”应用程序的过程中？不计算...
@Vinvq1987 用伟大的 Inigo Montoya 的话来说，“我认为你应该停止使用这个词。我不认为它意味着你认为它的意思。” “旧版”通常表示基于有些过时的技术或实践构建的已部署的功能性应用程序，这些技术或实践可能会被替换，但主要是实现其预期目的。尚未部署/构建==不是旧版。
为了成为魔鬼的拥护者，我认为所有提交到代码库的代码都是遗留的，我知道我不是唯一有这种感觉的开发人员。如果您不采取这种立场，您将面临不改进/重构代码的风险。 XP/TDD 的红/绿/重构实践有助于鼓励您永远不会对您的工作感到满意，即使在您刚刚完成工作之后也是如此。
我们始终努力改进该领域的内容。然而，遗产在开发环境中具有特定的含义。也许这是程序员的事情，但我重视特异性，因为它使沟通更加有效和富有成效。

【解决方案5】：

我过去通过使用（显然现在在阁楼上积灰）超轻量级映射器iBatis 来区分差异，iBatis 查询定义 XML 中的一些额外属性指示单个/多个结果集行为，以及一个 XSLT 样式表，它读取查询定义并为一个漂亮的 DAL 类输出源代码。

使用这种方法，您可以插入存储过程或直接 SQL。您确实错过了尖端 ORM 的一些更好的功能，例如 LINQ 支持和内存缓存，但是您在处理 80/20 规则偏差时也少了很多麻烦，这些偏差往往出现在以前的架构中。 '最初构建时并未考虑 ORM。

【讨论】：

我编写了一个代理类生成器，它构建 DAL 类并根据表定义生成 CRUD 过程。所有表都有公共列（我会，创建日期，删除日期（可为空））。这些类是部分的，因此它们很容易扩展，并且可以轻松地增强/修改存储过程。效果很好，在不牺牲功率的情况下节省了大量时间。

【解决方案6】：

ORM 不是“现代”的，它们旨在最大限度地减少与数据库的交互，以至于您通常不必编写 SQL。这也是您使用 SQL 存储过程和函数获得的结果，假设您团队中有一名数据库开发人员致力于开发和维护。

在 ORM 中支持原生 SQL 越来越普遍，因为它们处理复杂 SQL 的能力有限，这是可以理解的。人们对 SQL 开发有问题，我不认为软件抽象会更好......

“传统方式”更有针对性，与使用 ORM 相比，执行速度更快。 ORM 的好处是支持多个数据库供应商，而无需了解每个供应商的复杂性或 SQL 本身。

我会学习 ORM 以获得就业的可能性，最好知道何时使用它。

【讨论】：

【解决方案7】：

这取决于您最熟悉的语言以及您正在开发的平台。基于该标准，我建议学习一个 MVC 框架，它会强制您使用良好的 ORM 实践。在那个领域，Ruby on Rails（基于 Ruby）和CakePHP（基于 PHP）非常适合 Web 开发。尽管在 ORM 方面不那么严格，但如果您喜欢 PHP，ZEND 框架也非常好。如果您正在使用 MS SQL Server 或正在为桌面开发，.NET MVC 是您的最佳选择，它与任何 .NET 语言兼容。

这些框架将迫使您遵守良好的编码实践，因此您将获得更好的代码。它们还自动抽象数据库模式，创建与数据交互的对象和方法。学习曲线一开始可能看起来像一场艰苦的战斗，但一旦你了解了这些概念，语言的基础知识就会发挥作用，你就会成为一名超级程序员！

还有快速应用程序开发 (RAD) 的额外优势。使用大多数 ORM 框架启动和运行一个工作应用程序真的很容易和快速。它们可以在开发生命周期中节省大量时间。

【讨论】：

我认为 MVC 和 ORM 是正交技术。