如何鼓励自己切换到ORM？

Question

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

然后，我应该切换到ORM吗？如果是的话，请鼓励我。

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

非常感谢你。

Answer 1

以下三个原因是不切换：

1. Oracle PL / SQL是一种完整的编程语言。它不仅仅是一些冻结的SQL语句和一些条件编程。因此，PL / SQL层很可能包含无法在ORM中轻松实现的逻辑。

2. 众所周知，Oracle数据库许可证很昂贵。最大化ROI的最佳方法是利用内置功能。这对于ORM工具来说更难以处理，有时甚至是不可能的。

3. 您将应用程序描述为“遗留”，表明它正在生产中。如果是这样，改变数据访问架构将是一种彻底的放纵。您和您的同事将花费大量时间编写代码，更不用说整个应用程序的回归测试，对您的用户没有明显的好处。

Answer 2

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

ORM中越来越常见的是支持本机SQL，因为它们处理复杂SQL的能力有限。人们对SQL开发有问题，我不认为软件抽象会更好......

“传统方式”更具针对性，使其比ORM更快地执行。 ORM的好处是支持多个数据库供应商，而不了解每个供应商或SQL本身的复杂性。

我会学习ORM的就业可能性，最好通过知道何时使用它来实现。

Answer 3

用你自己的话说：

• 你的队友更有经验
• 你必须来这里讨论讨论
• 你的队友已经有了一个可行的解决方案
• 你有一个迫在眉睫的截止日期

除了技术论点之外，我个人不敢根据这些事实开始讨论更改数据访问层。与您的同事讨论在新项目中使用ORM的问题。在一个正在运行的项目中，通过开始讨论已经采取的基本废弃措施，不要感到痛苦。

Answer 4

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

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

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

Answer 5

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

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

快速应用程序开发（RAD）还有其他优势。使用大多数ORM框架来启动和运行正常运行的应用程序非常简单快捷。它们可以在开发生命周期中节省大量时间。

Answer 6

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

使用这种方法，您可以插入存储过程或直接SQL。您确实错过了尖端ORM的一些更好的功能，例如LINQ支持和内存缓存，但是您在应对80/20规则偏差方面遇到的麻烦要少得多，这些规则偏差往往存在于模式中最初是以ORM为基础构建的。

Answer 7

SPROCS在我看来绝不是一个好主意。

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

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