.关于操作数据库的接口（Linq to SQL ）——转自csdn

1. 通用查询机制。
2. 事务保护机制。

如果过没有这些，就无法真正进行高层次的数据库操作。

引用 4 楼 lanruoshui 的回复:
如果要放在实体类中实现，怎么能做到接口对实体的描述易于扩展呢。

放在实体类中实现？那么这岂不是“竖井式思维”。那种所谓一句每一个实体类来实现DAL的做法不要也罢，实在是太滥太枯燥太臃肿太八股了吧。

正如我所改的接口所示，如果你要写一个通用数据库类，它就是一个数据库接口，它处理各种业务实体，而它自己不是业务实体。

例如在Linq to SQL 中要删除一组用户资料只要写：

C# code

using(var database=CreateMyDataContext())

{

(from u in database.Users where u.Monthly>15000 select u)

.ToList().ForEach(u=>{ database.Users.DeleteOnSubmit(u); });

database.SubmitChanges();

}

就这么简单，这才是“通用数据库操作”。哪里用得着八股地一个一个实体类去搞什么“通用数据库操作”？

如果八股地为了分层而分层，还不如不要分层，那样还少一些编程设计麻烦。

还是根据我#15楼所写的那两句Linq to SQL代码（我其实从来不使用Linq to SQL，只是知道它而已），我看到网上的一些“范例”，竟然要写什么User类的DAL类，把那句代码再嵌入什么User.Delete(Monthly)方法中，你是是不是脱裤子放屁啊？！

Linq to SQL本身就是高级别的DAL通用框架，直接在BLL中调用它来处理数据库中的User对象就可以了，还要自己在User类上写什么DAL么？

DAL只有这一点的东西，例如我的DAL接口：

C# code

using System;

using System.Linq;

namespace WuweiCommon

{

public interface IDomain : IDisposable

{

IQueryable<T> Cast<T>() where T : class;

void Insert<T>(T obj) where T : class;

void Update<T>(T obj) where T : class;

void Delete<T>(T obj) where T : class;

void Commit();

}

}

另一个实现它的抽象类Domain只是增加了“触发器和CacheDependency支持”功能，然后各种数据库的DAL是从这个抽象类继承来的（于是也就具有IDomain接口）。
其实这个东西很简单，正因为简单，你就应该从难点入手，而不是纠缠于简单的东西（因为回避难点而好几年都在那里原地踏步）。正如#15楼的简单demo演示的，在BLL代码中调用通用DAL进行编程的需求会很灵活，你可能在开发时随时想更改where之后的条件，甚至多种类型对象进行join操作等等，那种在实体类上面搞个DAL类的做法怎么应付得来对真正的开发效率的需求呢？