我在一家仅使用存储过程进行所有数据访问的公司工作，这使我们的本地数据库保持同步非常烦人，因为每次提交都必须运行新的proc。过去，我曾经使用过一些基本的ORM，但是我发现使用它的经验要好得多，更干净。我想向开发经理和团队中的其他成员建议我们考虑使用某种ORM进行未来开发（团队中的其他成员仅熟悉存储过程，而从未使用过其他东西）。当前的体系结构是.NET 3.5，类似于.NET 1.1，具有“神类”，它们使用ActiveRecord的奇怪实现并返回在代码隐藏文件中循环的未类型化数据集-这些类的工作方式如下：
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...几乎没有任何设计模式的应用。根本没有任何测试（其他人都不知道如何编写单元测试，并且通过手动加载网站并四处浏览来完成测试）。查看我们的数据库，我们有：199个表，13个视图，多达926个存储过程和93个函数。大约有30个左右的表用于批处理作业或外部物品，其余的用于我们的核心应用程序。
在这种情况下，甚至值得采用其他方法吗？我说的是向前发展，因为“因为它可以工作”，所以我们不允许重构现有代码，因此我们不能更改现有类以使用ORM，但是我不知道我们多久添加一次全新的模块添加/修复当前模块的过程，因此我不确定ORM是否是正确的方法（对存储过程和数据集的投入过多）。如果是正确的选择，我该如何提出使用它的理由？我想到的唯一好处就是拥有更简洁的代码（尽管可能不是，因为当前的体系结构不是 考虑到ORM的构建，因此我们基本上是将ORM移植到将来的模块上，但旧模块仍将使用DataSet），而不必记住已经运行了哪些过程脚本以及需要运行哪些过程脚本，等等，仅此而已，我不知道这样的论点有多么令人信服。可维护性是另一个问题，但除了我以外，似乎没有人关心。
8
听起来您比仅仅说服团队使用ORM还要麻烦得多。在我看来，您的团队并不了解某些良好的开发实践（例如，设计模式，单元测试）。这些是您需要解决的更重要的问题。
—
伯纳德
具有讽刺意味的是，我认为在大约5年的发展中，我只遇到了少数几个了解设计模式和单元测试之类的人员/团队。通常我是公司中唯一了解这些事情的人。
—
韦恩·莫利纳
@Wayne M：我觉得有点令人不安，但是对此我也并不感到惊讶。
—
伯纳德
我发现这非常令人沮丧。当您提出建议并得到“头灯中的鹿”外观表示其他人对您所谈论的内容或任何人为什么会考虑这样做的模棱两可的想法时，这很奇怪。我过去曾发生过多次。
—
韦恩·莫利纳
我是存储过程的忠实拥护者，因此我的评论有偏见，但我完全不同意整个前提。您喜欢ORM，并且想使用它就可以了。但是，团队的其他成员都可以使用存储过程。为什么要强迫他们达到自己喜欢的程度？
—
2011年