编写自己的数据访问/数据映射层是“好”主意吗？

当前，我们处于选择使用现成的对象关系映射器或滚动自己的关系的情况下

我们有一个遗留应用程序（ASP.NET + SQL Server），其中数据层和业务层不幸地混在一起。该系统在数据访问方面并不是特别复杂。它从一大组（35-40）相互关联的表中读取数据，在内存中进行处理，然后以摘要格式将其保存回其他表中。现在，我们有机会进行一些重构，并且正在寻找可用于分离和正确构建数据访问的候选技术。

无论我们决定采用哪种技术，我们都希望：

• 在我们的域模型中具有持久性忽略的POCO对象
• 有一个抽象层，使我们可以根据模拟的基础数据源对域模型对象进行单元测试

显然，在模式和框架等方面已经有很多东西。

我个人正在推动将EF与ADO.NET单元可测试存储库生成器/ POCO实体生成器结合使用。它满足了我们的所有要求，可以轻松地捆绑在Repo / UnitOfWork模式中，并且我们的数据库结构相当成熟（已经进行了重构），因此我们不会每天对模型进行更改。

但是，小组中的其他人则建议完全从头开始设计/发布我们自己的DAL。（自定义DataMappers，DataContext，存储库，无处不在的接口，过分依赖以创建具体对象，自定义LINQ到底层查询翻译，自定义缓存实现，自定义FetchPlan实现...），该列表不胜枚举，直言不讳我是疯子。

引发的一些争论是“至少我们将控制自己的代码”或“哦，我在先前的项目中使用过L2S / EF，这无非是头疼”。（尽管我以前在生产中都使用过，发现任何问题很少而且相差不大，而且很容易处理）

因此，您在超级经验丰富的开发人员/架构师中是否有任何智慧的言语可能会帮助我将这个产品从我看来将是一场彻底的灾难中解脱出来。我忍不住想，通过规避EF问题而获得的任何利益，都将因尝试重新发明轮子而同样迅速地丧失。

针对现有ORM的两个参数均无效：

“至少我们将控制自己的代码”

为什么不写自己的语言？您自己的框架？您自己的操作系统？并且确保您可以控制一切，创建自己的硬件也是一个好主意。

“哦，我在以前的项目中使用过L2S / EF，这无非是令人头疼”

EF已经足够成熟，并被许多人成功使用。这意味着声称EF只是头痛的人应该开始学习如何正确使用EF。

那么，您是否需要编写自己的ORM？

我不建议那样。已经有专业级的ORM，这意味着您仅在以下情况下才需要编写自己的ORM：

• 您有一个精确的上下文，其中所有现有的ORM由于某种原因无法容纳，
• 您确定创建和使用自己的ORM（而不是学习现有ORM）的成本要低得多。这包括将来的支持费用，包括另一个开发人员团队的费用，他们必须阅读数百页的技术文档才能了解如何使用ORM。

当然，没有什么可以阻止您出于好奇而编写自己的ORM来学习东西。但是您不应该在商业项目中这样做。

另请参阅我对“重新发明轮子而不后悔”问题的回答的第2至3点。您会发现重新发明轮子的不同原因在这里并不适用。

将Entity Framework用于所有普通CRUD东西（占代码的80％至95％），并将自定义数据访问代码用于需要优化的所有其余代码。 这应该可以解决那些争论您没有足够控制权的人的担忧。

这是一个好主意，当且仅当您可以（至少合理地）确定通过编写自己的代码至少可以节省与第一时间生成该代码相同的时间/精力。视情况而定，这样做也可能会影响您的日程安排，因此您也必须考虑到这一点。您还必须考虑长期维护问题。如果滚动自己的ORM，则需要永久维护它（或至少使用它的时间）。

底线是，它可以是有意义的，只是在适当的条件下。这些条件通常包括：

1. 您正在处理的项目相当大，因此成本会因大量使用而摊销。
2. 您的数据使用非常不寻常，以至于现有的库（或此类库）无法很好地满足您的目的。

冒着明显的风险，这两者是成反比的-如果您正在从事一个真正庞大的项目，那么即使每次单独使用都节省一点钱，也足以证明开发的合理性。相反，如果您的需求确实很特殊，那么每次使用都会收获很多，那么即使是一个相当小的项目，该工作也可能是合理的。

至少基于您的描述，但这两种方法都不适用于您的情况。也许一个（或两者都）适用于您的同事以前使用EF，或者他只是有偏见-我认为您没有给我们提供足够的信息甚至无法猜测哪个（尽管公平地说，我想d猜测是因为他对您的猜测还不够。

如果我负责这种情况，我想我和您以及您的同事都应该写一份立场书-每种方法所见优点和缺点的清单，以及支持每种主张/主张的真实证据/随你。然后，整个团队将开始（即被要求）批判每篇论文。他们的批评的主要观点是在两个等级上对每个观点进行评分：

1. 该观点在多大程度上似乎是准确的，并得到事实等的良好支持，以及
2. 该点似乎适用于当前项目的程度。

然后，我会对论文和评论进行评估，以得出一个决定（尽管说实话，可能很难说出我使用它们多少来做出决定，以及我使用它们多少来为一个决定辩护）我已经做过了-我知道我可能不应该承认这一点，但现实情况是我也是人类...）

编辑：

如果我想变得特别讨厌（或“受教育”，在这种情况下很难说出区别），我希望你们每个人都尝试使用现有的ORM / DAL以及开发你自己。虽然这只是一个猜测，但我立即想到的是，大多数制定宏伟计划的人都不会费心上交自己的估计，直到他们提出一个总体工作估计，而这个估计甚至还遥不可及（而且很现实），他们意识到，他们甚至不可能与使用现有代码竞争。同时，

编辑2 ：（在@CmdKey的建议下进行）：尽管没有明确提及，但我认为估算值将隐含风险评估。特别是，时间估计通常应包括PERT样式的数字：

1. 如果一切顺利的话，最快的最好的情况是可以做到的。
2. “正常”估算值-您预计需要多长时间。
3. 如果一切出错，最坏的情况可能是最长的估计。

当然，最佳和最差情况的估算通常不应包括直接的神职干预之类的东西，而应包括几乎所有其他东西。

通常，重新发明轮子从来不是一个好主意，而这样做通常是技术上的愚昧（“我什么都不知道，也不想学习”）或傲慢（“ X很愚蠢，我可以在两周内编写自己的工具！“）; 有一些成熟的工具可以做的事情比一些普通的开发人员可以在几周内共同破解的事情要好得多。

话虽这么说，但有时您无法在不进行大量工作的情况下将旧应用程序可靠地适合现有解决方案（无论其灵活性如何）。在这样的情况下，这不是一个“好”主意，而是比其他选择更好的主意（即保持原样，或重写其中一半以便能够使用第三方层），因此您别无选择。

由于存在Hibernate中不存在的一些“关键”功能，我在一个项目中拒绝了现有的Java ORM工具来编写自己的工具。这是一个数百万美元的错误，而且成本每天都在增加。他们仍然不完全支持对象关系。因此，除了花费所有时间来创建和维护框架之外，他们还花费了数小时来编写可以使用Hibernate在几分钟内编写的代码，或者在许多情况下根本不需要编写代码。

现有的框架是数十年的努力的产物。想象一个团队可以在几个人周内接近任何地方，这是荒谬的天真。

您必须编写的代码就是您必须维护的代码。维护ORM代码所花费的时间就是不维护应用程序所花费的时间。除非ORM赋予您某种战略优势，否则它不会为业务带来收益，因此纯属开销。您的公司是愿意花钱在日常开支上还是增强赚钱产品？如果这是针对内部应用程序的，那么这可能不是问题，但是您仍在增加需要编写，测试和记录的代码量。

我想说，推出自己的ORM是一个坏主意-除非您有一个非常非常上帝的理由这样做（顺便说一句，您引用的内容还不够好：）

一旦让别人说服我不要使用ORM，我就犯了一个错误，我可以告诉你，我们自己编写所有DAL确实减慢了我们的工作速度，而不是实现对业务重要的功能，我们花了一些时间在DAL上（这需要做很多工作）比它看起来的样子）。

新的EF效果很好，但是如果您需要更多控制权，我可以考虑以下微型ORM：Drapper http://code.google.com/p/dapper-dot-net/或PetaPOCO http ：//www.toptensoftware.com/petapoco/

您也可以混合搭配-使用EF填充大部分内容，使用Drapper进行一些微调。

无论如何，这只是我的2分;）