比如说数据库表增加了一个字段,那么你在 EF 的 Model 定义中增加一行代码(属性定义)来对应这个新的字段就行了,这样以 EF 为 DAL 的修改就完成了。那么“挺麻烦”的点在哪里呢?其实可以相见,都跟据数据库无直接关系,是个设计理念问题。
真正的设计,是从前端出发的。比如说直接修改模板,绑定了一个新的字段,然后运行,这时候你发现编译出错,因为 Model(或者 ViewModel)没有这个字段的定义。这时候你就可以在 Model 中增加这样字段,于是编译恢复正常。
这才是开发的方法。是从产品设计、用户需求触发,而不是从数据库表来拼凑界面设计的。
Model 是跨前端和后端的,而 DAL 不过就是输出某种 Model 实体对象,它其实跟 MVC 无关,它是 M 后边的(底下的、单机的)东西。你可以使用 ADO.NET 读取数据库然后产生 Model 实体也是一样的,你可以在一个程序中使用3、4种 DAL 框架技术——哪种方便就用哪种——同时使用。
因此,使用 ADO.NET 纯粹 sql 字符串然后手动产生一个一个面向对象的实体对象,还是使用 EF 现成的机制来自动 ORM 编程,那是可以同时并存的。这就好像搬砖的人眼中有各种砖需要搬,但是它不能把搬砖说成是建筑艺术,他要理解建筑师的考虑才能不限于总是思考搬砖。