导读：使用动态数据库访问对象很大程度简化了我们的操作，为了使我的介绍更形象化，也易于大家理解，下文中我将通过一些实例简单的介绍下这种方法。

前两天看到Warp framework的介绍，它基于Google Guice，是一个轻量级的web开发框架。它的Dynamic finder特性实在让人兴奋，代码非常简单，支持注入，大大简化了DAO层的开发。下面看看它的几个例子吧:

@Finder(query="from Person") public List<Person> listAll() { return null; }

@Finder(query="from Person where firstName = :firstName") Person find(@Named("firstName") String name);

还有更简单的吗

在以往的开发过程中，为了层次清晰，易于测试，通常会将业务逻辑层和数据库访问层分开。看下面的例子

public class UserService { public UserService(IUserDAO userDAO){} } 为什么要这样做呢？

好处是：

1. userDAO能够依赖注入，使用IOC框架管理

2. 对UserService进行单元测试，userDAO使用mock工具创建，这样避免了要单元测试还得生成真实数据的问题。

但是这样就产生了一个问题，大部分数据表都会有这么一个DAO对象存在，使得DAO层过于庞大。当然如果使用泛型的DAO或者抽象出基类就能使代码量减少，这样也不能解决根本问题。Warp提出的Dynamic finder，让人着实兴奋。自己根本就不需要逐个DAO去实现，只需要方法声明+annotation。

这么好的想法怎么能不采用呢。 于是我花了几个小时试着用C#来实现，并且结合了Linq To Sql。如果直接使用SqlCommand来操作数据库填充实体，实现起来会更加简单，现在用Linq To Sql的人越来越多，就结合着来写的。结果还不错，代码看着的确简洁了很多，就是接口+Attribute。我使用的数据库是Northwind。Customer是Linq To Sql生成出来的，EntityType是用来标识对那个实体类进行操作，Find用来标识根据主键查找对象的方法，Delete表示是删除一个实体，Create表示创建一个实体。Query表示自定义的查询字符串，现在只是最简单实现，以后可以提供更复杂的查询条件和写法。

[DomainType(typeof(Customer))] public interface ICustomDAO

从上文可以总结出使用动态数据库访问对象好处还是很多的，希望大家通过本次的学习，能够掌握这种技巧，这样就能为对大家以后的工作带来种种益处，大家何乐而不为呢？