在MVC中一个设计好一点的MVC+三层中，Dal层应该具备哪些通用或者说必备的方法

DAL层有两类，一类是通用的框架，例如你可以使用 EF 或者自己写个 SQLHelper，另一类就是把围绕各种业务对象和查询逻辑而写一大堆“死 的”API方法。后者的做法不推荐。说白了，你无需写DAL层代码，因为凡是通用的东西都已经有人写好了，只是好用不好用的问题，逻辑是否复杂的问题。有 的人在 DAL 中写一大堆业务逻辑，把原本应该写到 BLL 层的代码写到 DAL层中，这反而是坑爹的做法。所以你不写 DAL层而是使用现成的框 架，更好！

 

DAL层就是关系数据库（一般来说是关系数据库。如果你使用 Mogodb之类的，那么也可以包括 ODBMS）与你的程序对象的适配层。例如你给一 个 IQueryable<T> 类型查询对象，DAL层就会自动动态编译为 sql 查询语句并且将查询结果自动装配到 T 类型的对象中 返回，甚至自动处理对象属性的子类型对象查询（一个查询通常需要涉及5、6个数据库表），这都是 DAL 层的范畴。

DAL 就是一个比较通用的数据库引擎层，只开发一次就能用到多个项目中。所以你最好不要写什么具体项目的个性化的业务对象到DAL层，而是研发一个通用的 DAL 层用于多种项目。

三层也好，MVC概念也好，其中的 Model 以及相关的数据传输操作或者后台数据库引擎操作，其实都是非常低级非常简单的功能，占开发时间的不足 5%。一些很爱纠结数据库表结构的人往往花50%的时间去消耗在这个上面，而且没有灵活性、经常推倒了表结构设计重来，缺乏长远也缺乏即时行动力。

实际上设计一个好用的“前端‘应用系统，30%的时间在于需求调研和UI逻辑页面原型设计，10%可能在于调用相关引擎进行表单流设计和配置，剩下几乎所 有时间用来现场快速生成千变万化的UI界面，几百个上千个数据库表也不过就是画画用户表单就自动生成，真正的要注意到的就是要100%符合用户的灵活高效 率的操作要求，甚至往往大大超出用户能想到的范围。我们对前端小蜜蜂论坛发帖机开发人员的开发效率要求，培训2个月之后，起码比绝大多数未经培训的前端程序员的开发效率， 高几百倍。

如果你用 ef之类的。
那么可以不用 dal层。