最近比较清闲,正好利用这个时间仔细研究了一下Asp.net的多层架构,主要参考的是 Wrox 的一本<.Net WebSite Programming Problem-Design-Solution>,个人觉得这本书写的不错。面向有一定.net基础的开发人员,刚开始看起来可能觉得很难懂,但是仔细研究一下会发现,这本书是一本面向工程应用的优秀参考手册。
Asp.net的多层架构主要是为了解决数据层,逻辑层,表示层等之间的关系。我的做法是这样的:首先建立一个DataCore的基类。基类里面封装了一些低层的数据库的基本操作,比如说数据库联接,调用存储过程等等。在这里面有一个地方值得注意,通过对一个函数的重载可以实现调用不同功能的存储过程。以下代码示例:
protected int RunProcedure(string storedProcName, IDataParameter[] parameters, out int rowsAffected )
{
int result;
Connection.Open();
SqlCommand command = BuildIntCommand( storedProcName, parameters );
rowsAffected = command.ExecuteNonQuery();
result = (int)command.Parameters["ReturnValue"].Value;
Connection.Close();
return result;
}
protected SqlDataReader RunProcedure(string storedProcName, IDataParameter[] parameters )
{
SqlDataReader returnReader;
Connection.Open();
SqlCommand command = BuildQueryCommand( storedProcName, parameters );
command.CommandType = CommandType.StoredProcedure;
returnReader = command.ExecuteReader();
//Connection.Close();
return returnReader;
}
protected DataSet RunProcedure(string storedProcName, IDataParameter[] parameters, string tableName )
{
DataSet dataSet = new DataSet();
Connection.Open();
SqlDataAdapter sqlDA = new SqlDataAdapter();
sqlDA.SelectCommand = BuildQueryCommand( storedProcName, parameters );
sqlDA.Fill( dataSet, tableName );
Connection.Close();
return dataSet;
}
protected void RunProcedure(string storedProcName, IDataParameter[] parameters, DataSet dataSet, string tableName )
{
Connection.Open();
SqlDataAdapter sqlDA = new SqlDataAdapter();
sqlDA.SelectCommand = BuildIntCommand( storedProcName, parameters );
sqlDA.Fill( dataSet, tableName );
Connection.Close();
}
道理很简单,一看就懂。对于以后的操作有好处的。
其次是要建立逻辑层,这个逻辑层基本上就是实例化数据层DataCore之后为表示层返回一些DataSet,DataReader之类或是执行一些insert,update,delete之类语句。这个逻辑层也是为了区分整个Project下面不同功能模块。比如说用户模块起名叫做UserModel.cs,新闻模块叫做NewsModel.cs之类。逻辑层的另一个好处就是可以为表示层建立可以多次实例化的同一个对象或是方法。比如说User类,通过ID或是Username 查询并建立的对象可以被表示层多次调用。
最后是表示层,表示层的功能就是完成页面逻辑。主要是接受客户端数据然后经过简单整合和判断,传递给逻辑层处理。同样,接收逻辑层传递来的Dataset或DataReader,表示在前台页面。
数据在各个层次之间的关系相对独立,但是又相对连续。
独立性:
对于表示层之外的几个层,都可以把单个的对象或是方法直接拿出来放到其他工程中。因为每个曾都是为了实现模型中独立的功能而完成的。因为在类似工程中的应用基本上不用太大改动,特别是一些相对更加原始的层,在这个示例中的DataCore就是一个典型的例子。
连续性:
数据在传递过程中有较强的连续性。举一个例子,在表示层中有这样一个根据Session中Userid返回一个Dataset,原本我是这样写的:
表示层:
DataSet UserInforRow = ObjectUser.GetUserInfor(Int32.Parse(Session["UserId"].ToString()));
逻辑层:
public DataSet GetUserInfor(int UserID)
{
SqlParameter[] parameters ={new SqlParameter("@UserID",SqlDbType.Int,4)};
parameters[0].Value = UserID;
using(DataSet UserInfor = RunProcedure("GetUserInfor",parameters,"UserInfor"))
{
return UserInfor;
}
}
这样可以编译通过,但是在执行的时候提示错误,类型不匹配,语法上面没有错误。但是错误出在,表示层传进来的是一个Int32,在Sqlparameter中确是一个Int,4,本来以为这样的变量类型都是在每一个层次中相对独立的,但是当他们之间传递数据的时候,出现了问题。
对于这个问题的解决方案有两种,无非是更改表示层还是更改逻辑层。更改逻辑层,就要改成
SqlParameter[] parameters ={new SqlParameter("@UserID",SqlDbType.Int,32)};
更改表示层要改为:
DataSet UserInforRow = ObjectUser.GetUserInfor(int.Parse(Session["UserId"].ToString()));
两个方案中显然是更改表示层比较合理,因为不能够因为一个变量的传递更改变逻辑层中的可以被其他表示层页面所调用的方法。
其他类似的变量传递和引用也遇到类似问题,虽然几个层次相对独立,但是在数据的传递上也相对连续。
.net在web上面的应用可以做的很复杂,逻辑也很强,简单的单页面调用不是.net的特点也不能作为工程应用。我也是接触了一点,冰山一角,希望能起到一个抛砖引玉的作用.
Asp.net的多层架构主要是为了解决数据层,逻辑层,表示层等之间的关系。我的做法是这样的:首先建立一个DataCore的基类。基类里面封装了一些低层的数据库的基本操作,比如说数据库联接,调用存储过程等等。在这里面有一个地方值得注意,通过对一个函数的重载可以实现调用不同功能的存储过程。以下代码示例:
protected int RunProcedure(string storedProcName, IDataParameter[] parameters, out int rowsAffected )
{
int result;
Connection.Open();
SqlCommand command = BuildIntCommand( storedProcName, parameters );
rowsAffected = command.ExecuteNonQuery();
result = (int)command.Parameters["ReturnValue"].Value;
Connection.Close();
return result;
}
protected SqlDataReader RunProcedure(string storedProcName, IDataParameter[] parameters )
{
SqlDataReader returnReader;
Connection.Open();
SqlCommand command = BuildQueryCommand( storedProcName, parameters );
command.CommandType = CommandType.StoredProcedure;
returnReader = command.ExecuteReader();
//Connection.Close();
return returnReader;
}
protected DataSet RunProcedure(string storedProcName, IDataParameter[] parameters, string tableName )
{
DataSet dataSet = new DataSet();
Connection.Open();
SqlDataAdapter sqlDA = new SqlDataAdapter();
sqlDA.SelectCommand = BuildQueryCommand( storedProcName, parameters );
sqlDA.Fill( dataSet, tableName );
Connection.Close();
return dataSet;
}
protected void RunProcedure(string storedProcName, IDataParameter[] parameters, DataSet dataSet, string tableName )
{
Connection.Open();
SqlDataAdapter sqlDA = new SqlDataAdapter();
sqlDA.SelectCommand = BuildIntCommand( storedProcName, parameters );
sqlDA.Fill( dataSet, tableName );
Connection.Close();
}
道理很简单,一看就懂。对于以后的操作有好处的。
其次是要建立逻辑层,这个逻辑层基本上就是实例化数据层DataCore之后为表示层返回一些DataSet,DataReader之类或是执行一些insert,update,delete之类语句。这个逻辑层也是为了区分整个Project下面不同功能模块。比如说用户模块起名叫做UserModel.cs,新闻模块叫做NewsModel.cs之类。逻辑层的另一个好处就是可以为表示层建立可以多次实例化的同一个对象或是方法。比如说User类,通过ID或是Username 查询并建立的对象可以被表示层多次调用。
最后是表示层,表示层的功能就是完成页面逻辑。主要是接受客户端数据然后经过简单整合和判断,传递给逻辑层处理。同样,接收逻辑层传递来的Dataset或DataReader,表示在前台页面。
数据在各个层次之间的关系相对独立,但是又相对连续。
独立性:
对于表示层之外的几个层,都可以把单个的对象或是方法直接拿出来放到其他工程中。因为每个曾都是为了实现模型中独立的功能而完成的。因为在类似工程中的应用基本上不用太大改动,特别是一些相对更加原始的层,在这个示例中的DataCore就是一个典型的例子。
连续性:
数据在传递过程中有较强的连续性。举一个例子,在表示层中有这样一个根据Session中Userid返回一个Dataset,原本我是这样写的:
表示层:
DataSet UserInforRow = ObjectUser.GetUserInfor(Int32.Parse(Session["UserId"].ToString()));
逻辑层:
public DataSet GetUserInfor(int UserID)
{
SqlParameter[] parameters ={new SqlParameter("@UserID",SqlDbType.Int,4)};
parameters[0].Value = UserID;
using(DataSet UserInfor = RunProcedure("GetUserInfor",parameters,"UserInfor"))
{
return UserInfor;
}
}
这样可以编译通过,但是在执行的时候提示错误,类型不匹配,语法上面没有错误。但是错误出在,表示层传进来的是一个Int32,在Sqlparameter中确是一个Int,4,本来以为这样的变量类型都是在每一个层次中相对独立的,但是当他们之间传递数据的时候,出现了问题。
对于这个问题的解决方案有两种,无非是更改表示层还是更改逻辑层。更改逻辑层,就要改成
SqlParameter[] parameters ={new SqlParameter("@UserID",SqlDbType.Int,32)};
更改表示层要改为:
DataSet UserInforRow = ObjectUser.GetUserInfor(int.Parse(Session["UserId"].ToString()));
两个方案中显然是更改表示层比较合理,因为不能够因为一个变量的传递更改变逻辑层中的可以被其他表示层页面所调用的方法。
其他类似的变量传递和引用也遇到类似问题,虽然几个层次相对独立,但是在数据的传递上也相对连续。
.net在web上面的应用可以做的很复杂,逻辑也很强,简单的单页面调用不是.net的特点也不能作为工程应用。我也是接触了一点,冰山一角,希望能起到一个抛砖引玉的作用.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1603534