问题由来

最近在研究适合团队开发的web架构解决方案，该架构即要适合分工协作又要有一定扩展性，适合不同的数据库需要，因此我查阅了一些资料，初步构想出了一套架构，请各位多多指教。

探索

web开发架构最经典莫过于三层架构，表示层、逻辑层、数据处理层。

数据访问层：其功能主要是负责数据库的访问。

业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。

表示层：是系统的UI部分，负责使用者与整个系统的交互。理想的状态是表示层不应包括系统的业务逻辑。

这些是经典的解释，如果要适合不同的数据库则需要加入工厂模式，里面用面向接口的方式进行多态调用。是不是这有点像petshop了。所以架构的初步设想是这样：

下面以获取用户信息为例，简述这个架构的流程：（以下为类似petshop的经典做法，了解的可以略过）

step 1 、首先我们应该建立项目所需的实体模型，在这里新建用户信息的实体模式，UserInfo.cs。该类保存在Model项目里。

step 2 、我们再将项目的单元功能写到相关的接口中，这里以获取用户信息功能为例。在IDAL项目里新建IUser接口。

        //根据用户ID获取用户信息
        UserInfo GetUserById(int userId);

step 3、完成了接口，我们就要实现它，现在我们用sqlserver、oracle两种数据库访问方式来实现它。以下是SqlserverDAL中User类对接口的现实：

public class User:IUser
    {

       
        public UserInfo GetUserById(int userId)
        {
         //实现操作           

        }

    }

OracleDAL中现实方式类似。。。。

step 4、在此数据库访问层应该就基本写好了，下面应该给逻辑层调用了，但是两种实现方式怎么调用呢，或者说怎么有选择的调用它呢，petshop是这样处理的，在DALFactory中的DataAccess类，利用反射载入程序集从而实例化所需要的类：

        private static readonly string path = ConfigurationManager.AppSettings["WebDAL"];
        public static IUser CreateUser()
        {  

            string className = path + ".User";
            return (IUser)Assembly.Load(path).CreateInstance(className);

        }

至于要选择哪个数据库访问层，在配置文件里配置一下WebDAL。如：<add key="WebDAL" value="SQLServerDAL"/>。

这样就基本解决了逻辑层和数据访问层的耦合。

step 5、下面就该写逻辑层了，在BLL里面创建User.cs类。大致如下：

public class User
   {
       private static readonly IUser dal = DALFactory.DataAccess.CreateUser();

       public UserInfo GetUserInfo(int userId) {
            return dal.GetUserById(userId);
        }

   }

是不是觉得BLL毫无意义，因为它只是对数据访问层方法的简单调用，但并不是这样的，这里只有一个简单的事例，在实际项目中一个BLL里面处理的可能是一个非常复杂的逻辑，而这个复杂逻辑的结果才提供给表示层显示。

step 6、最后是表示层，好像没什么可说的，把从BLL取出来的数据绑定到你的页面就行了。

以上是仿petshop的架构设计，看起来没什么质疑的地方，毕竟是微软的经典案例。你可能抱怨的地方有两点，一是层是不是有点多，关系过于复杂；二如果我需要改变或增加一个数据库字段，那不是会很痛苦，因为要节联修改。这两个问题，我都没办法解决，一如果说过于层过于多而繁琐，那么下面我写的好像更为复杂，原谅。。。。二、鄙人觉得凡是分层开发，只要以数据库字段为依据的建立实体模型，都会存在节联修改的问题。除非全部用DataTable，那么在BLL、表示层调用