有一次和同事讨论起具体的技术细节，同事说不要用什么实体类，从数据库访问到的数据，直接用DataTable、DataSet 就好。理由是，从获取到的数据集转换成实体类，有一定的性能损耗。
呵呵，性能。我们总是有这种无端的担心，一副十分神秘的样子。既然如此，那么为什么还要有ORM、EF这些思想、框架呢？难道创建这些东西的大师们都是在故弄玄虚，过度设计？如果将DataTable转换成实体类有性能损耗，那么这种损耗究竟有多大？跟由此换来的逻辑清晰、开发效率提升是否可以忽略不计？
正如汇编语言的效率高于C、C++等高级语言，但现代操作系统绝大部分功能都用C或C++进行编写。理由是：
1）性能主要在于算法，开发语言之间的性能差距并不起决定性作用
2）高级语言带来的逻辑清晰、代码重用及模块化，结合现代编译技术，有可能比所谓的汇编高手所写的代码性能更好。尤其是复杂性高的模块，人脑跟机器是没办法相比的
3）编译技术的改进，对源代码进行重新编译，可以得到性能更高的成品
4）开发过程中，先使用C等高级语言编写，调试、定位成功以后，关键部分再采用汇编改写，这种思路更利于成功
另外，同事说，使用DataTable和使用实体类并没有区别。“想想看，如果增加了一个字段，实体类不是照样要修改吗？引用实体类的代码也要相应修改，这跟使用DataTable有什么不同？”同事理直气壮地问我。
我一时语塞，想不出什么理由反驳，只好弱弱地说：“那字段名修改了，实体类的属性可以不一定修改”
“通常，数据库的字段名字改了，实体类属性也要改吧，不然容易误解”
我更加哑口无言，无奈地说：“但是将数据库的东西，直接塞在前端，即UI层面，总不大好吧。。。“。说实在的，为什么要分层，为什么要将数据与UI分离，我只是人云欲云。虽然我认同分层确属必要，但这个问题我真没好好考虑过。
不过后来我静下来想了想，增加字段、改字段名、字段类型，实体类照样要修改没错；但如果去掉一些字段，那么实体类方式的优势就出来了。假如页面端直接用DataTable 访问，那么字段去掉以后，编译阶段，是发现不了错误的；但实体类不同，数据库字段删掉了，实体类应该也跟着删掉了相应属性，那么所有调用这个实体类属性的地方，编译时就会报错。如果我们在VS中，使用重构，还可以自动修正过来。
版权声明：本文为博主原屙文章，喜欢你就担走。