你应该选择和使用ADO.NET Entity吗？

前前后后，花了大约一个周的时间学习ADO.NET Entity，问题一直都很多。学习的出发点是希望了解和掌握这门技术，提高开发的效率。但学下来感觉非常别扭，以是痛定思痛，决定好好研究下ADO.NET Entity的设计出发点和要达到的目标以是有了这篇文章。

现做一个简单的总结，希望对后来者有帮助，而不是一来就跟着代码走，结果把自己搞晕。

ADO.NET Entity 推出的关键是解决OO程序设计和关系数据库之间阻抗失谐，可参考网址：

http://msdn.microsoft.com/zh-cn/library/aa730866(VS.80).aspx#EGAA

http://msdn.microsoft.com/zh-cn/library/aa697427%28v=VS.80%29.aspx

http://msdn.microsoft.com/zh-cn/magazine/dd263098.aspx

这个听起来很美的技术在我实践后，发现并非如此。

1、为什么有阻抗失谐，而不是说关系数据的组织存储有问题或是面向对象编程有问题？

回答这个问题有点难，如果这两个问题中任何一个确实存在问题，那么都对现有的整个计算机系统提出巨大挑战。所以我先认为阻抗失谐是存在的。

 

2、什么是阻抗失谐：

在现代程序开发中，面向对象的方法论需要自上而下的进行系统实现（业务需求->面向对象的设计和建模->数据存储），而最终对象数据被存入关系数据库时由于两者针对的问题域不同导致的匹配问题称为阻抗失谐（例如关系数据库无法保存OO的封装、继承和多态）。

 

通俗的说：食古不化的关系数据库存储方式拖住了宇宙第一帅哥面向对象系统设计和开发的后腿。这有一个时髦的称呼：叫阻抗失谐。

 

3、阻抗失谐的表现方式：

3.1、在程序语言中出现编译器无法理解和调试的SQL字符串，及访问SQL结果集的字段名字符串

3.2、我们需要的是对象、但我们得到的是一个二维表

 

4、阻抗失谐问题的本质

考虑一下：从ODBC数据访问技术到阻抗失谐问题被公布并认同前，我们是怎么生活阻抗失谐这个问题中？以是我发现，在这个问题被认同前，处理问题的流程和方式是：

业务需求->关系数据建模->程序实现。于是：阻抗失谐问题消失了。在程序中出现SQL语句和二维表是应该的

 

个人认为阻抗失谐问题的本质是：采用什么方式来实现软件系统带来的问题。以数据库建模为主导、程序实现的方式，没有这个问题。以OO方式为主导，把数据库完全看为一种存储需求的方式，存在阻抗失谐。

 

5、是否选择ADO.NET Entity

问题讨论到现在、变成了一个类是先有鸡还是先有蛋的问题。但我们不应该在这个问题上纠缠。

 

如果你想从业务需求->面向对象的设计和建模->数据存储的方式来完成系统，那么可以考虑使用并开始学习并使用ADO.NET Entity。

 

如果你已经习惯了业务需求->关系数据建模->程序实现的开发方式，那么我不建立你学习和使用ADO.NET Entity。因为现有的方式ADO.NET支持的很好，而且一个完整的软件产品或经历了几年数据库应用程序开发的程序员应该已经有了很多与DB交互和管理代码而不只是简单有几条SQL或是一个DBHelper这样的东西，在转移代码时，学习成本和代码转移存在风险。

 

 

6、现在网上能搜到关于ADO.NETEntity的文章中，存在如下问题

1、大谈阻抗失谐、有夸大问题的成份。谁都不是银弹，我想这一点大家都明白

2、有意隐藏效率问题而夸大程序代码的直观和简洁性，完成ORMapping是需要硬件和时间成本的，新的语言表达方式也需要学习成本（事实上我立即看懂了存在阻抗失谐的代码，但没有立即看懂那些被称为更直观简洁的代码），对于复杂或大数据量的系统如何使用，并没有正面回复。

最后：我采用的是业务需求->关系数据建模->程序实现的开发方式。这也是我越学越别扭的原因。

所以ADO.Entity。再见。