c#项目开发的时候为什么要把数据表实体化，弄成好多个和表有关的文件

在主流的软件设计模式中，无论是MVC、MVP还是MVVM，都有个Model层，主要是将对象抽象为一个模型，从而使数据模型具有更好的可使用性，可扩展性，以应对比较复杂的规则变化。

就比如现在你有一个客户表C，你需要用一个表把所有的客户显示出来，你需要写一个“Select * from C”，这样看起来很简单；
然后规则变了，你需要在界面上放一个下拉框，根据客户名筛选客户，你需要先“Select Name from C”，把结果放到下拉框了，然后根据选择的值去拼接另一个Sql ：“
Select * from C
where Name =‘选中的值’”；
然后规则再变了，你需要在界面上再放一个单选框，根据性别筛选客户，于是你需要再次拼接Sql： “
Select * from C
where Sex =‘选中的值’”；

......
这样下去的结果就是，虽然需求只是极小的变动，但你不得不不停的更改底层的数据库访问方法，并且导致单元测试变的非常复杂；

好了，现在我们有了模型，那么我们就可以一个
“Select * from C”搞定这三个规则了，数据全部查出来，放到一个实体C_Info里，只要库结构不变，数据的模型就是稳定的，我们完全可以在不需要更改sql的情况下，操作数据模型去完成我们应对规则变化的方法。比如应对变化1和变化2，我们只需要从C_Info中筛选 C_Info.Name = "XX" 和 C_Info.Sex=“XX”就可以了。

当然，这只是最简单基本的举例，具体的好处工作中会慢慢体会到。 更多的你可以关注下设计模式。

效率自有微软优化。就看你怎么实体化了。

将数据组织实体化有助于开发者抽象数据关系，扩展数据逻辑。
什么东西都写成SQL语句很难维护。

如果是LINQ to SQL，只要不要每次都生成新的LINQ委托对象，就可以保证和旧式查询一样的效率，甚至更高。

这么做处理数据的时候方便啊，不然对着个表操作，多容易写错啊，存储也不方便