最近在开发项目的时候，在思考一个问题，就是有没有必要把业务逻辑层与数据访问层分离；在我开发的这个项目中，我采用的是codesmith自动生成数据访问层，业务逻辑层，以及一些简单的管理后台，我把生成的代码都放在一个DataProviderBasebase类里面，然后派生了一个空的类DataProvider，这个类是用来由用户编写自定义的代码的，我生成的数据访问层代码已经基本上包含大量的方法和接口，包括GetModelByPk,GetModelsByFk,GetAll,GetFeild,GetCount,GetPaged,GetModelByIX等众多常用的操作和重载,而且大部的的地方是入一个比较开放式的结构体做为参数，是一个SqlStruct实体，这个结构里面包含了commandText,CommandType,SqlParameter这些参数，可以说这个类可以完成所有的sql操作，而这个SqlStruct我是通过一个SqlBuilder语句生成类动态生成了来的！

也就说我只要一个SqlBuilder生成一个SqlStruct传递给相应的DataProviderBase（数据访问层）方法即可获取数据，我现在的想法是把逻辑访BLL层代码放到DataProviderBase的派生类DataProvider中（这个类生成后是空的）,这样一个是简化层次结构,大家觉得合适吗？

顺便帮忙分析下，有时想想，业务逻辑层在什么情况下才比较迫切的需要呢？

类结构:

     SqlStruct类:

Code
 /// <summary>
        /// sql语句
        /// </summary>
        public string CommandText{get;set;}
        /// <summary>
        /// sql数据库变量
        /// </summary>
        public SqlParameter[] SqlParameters{get;set;}
        /// <summary>
        /// 命令类型
        /// </summary>
        public CommandType CommandType{get;set;}

    SqlBuilder类,用于动态生成sql并返回SqlStruct类的实例

DataProviderBase类就是数据访问的操作了，包括获了实体，列表，统计等一系列的方法

DataProvider类继承自DataProviderBase类，是一个空的函数，主要用来给程序员手工编写代码的，我打算是把逻辑层的代码写在这里

声明下：现在的项目基本没有数据库变化的可能，用的是sql server 没有特别复杂的逻辑，是一个在线商城！