架构设计之首部曲

80酷酷网    80kuku.com

  架构|设计系统采用|B/S结构,共分三层,分别是数据访问层,业务规则层,Web外观层。它们各自有自己的职责,各自为政又互相配合从而形成一个软件的整体功能系统,数据访问层的职责是负责对数据源的存取(这里的数据源是指SQL Server 2000),业务规则层负责的是对数据按照业务流程的处理,Web外观层负责向用户提供交互的接口,只负责输入输出数据。这样设计是很普遍的,它提供了一个较好维护的体系。

设计:

1) 数据访问层:

很多人愿意在这一层封装大量的SQL脚本以简化上层的设计,但是这样的设计并不合适!业务一般情况下会有变化,如果把SQL脚本“硬编码”在一起,修改时不得不修改程序的源代码。而用户那里一般只有打包的二进制程序!所以较好的做法是将对数据的操作的脚本放在外面,一般是放在离数据近的地方,如SQL Server上,这里我们把它

编写成存储过程放在SQL Server服务器上。编写成存储过程有这样的两个好处:第一,业务改变时,只要改存储过程即可。第二,没有必要将大量的脚本通过网络传输到数据库服务器解析执行,给网络带来很大的负担。而是只是调用一个存储过程名而已,大大降低了网络负担和中间层的负担。 如:执行添加用户的操作

Create PROCEDURE dbo.User_Create

RealName varchar(50),

DeptName varchar(50),

HashedPassWord varchar(50),

Tel varchar(50),

Address varchar(50),

DutyName varchar(50),

UserName varchar(50)

AS

begin tran

insert into [User] (UserName,RealName,DeptName,HashedPassWord,Tel,Address,DutyName) values(UserName,RealName,DeptName,HashedPassWord,Tel,Address,DutyName)

if error!=0

begin

rollback

return 0

end

else

begin

commit

return 1

end



对于执行存储过程和维护和数据库连接状态的方法(如:ExecSQL(string SQL),Open())应当封装在一个公共类中共其他类使用,而不是每个类都有自己的数据库方法!这样的意图是可以减少重复依赖,而且如果将这个共享类的方法抽象出来成为一个接口,让所有用到他的类使用这个接口,在共享类发生变化时,使用它的类并不知晓这些变化,减少了依赖就意味着更好地适应变化!

如:

public class Database : IDisposable ,ISQLDataBase(参考于codePlus)

{

private SqlConnection con;

private DBConfig m_Config=DBConfig.Instance;

public int RunProc(string procName)

{

SqlCommand cmd = CreateCommand(procName, null);

cmd.ExecuteNonQuery();

this.Close();

return (int)cmd.Parameters["ReturnValue"].Value;

}

public int RunProc(string procName, SqlParameter[] prams)

{

SqlCommand cmd = CreateCommand(procName, prams);

cmd.ExecuteNonQuery();

this.Close();

return (int)cmd.Parameters["ReturnValue"].Value;

}
.......

}

接口:

public interface ISQLDataBase

{

int RunProc(string procName) ;

int RunProc(string procName, SqlParameter[] prams) ;

void RunProc(string procName, out SqlDataReader dataReader) ;

void RunCommand(string command,out SqlDataReader dataReader);

void RunProc(string procName, SqlParameter[] prams, out SqlDataReader dataReader) ;

SqlCommand CreateCommand(string procName, SqlParameter[] prams) ;

void Open();

void Close() ;

SqlParameter MakeInParam(string ParamName, SqlDbType DbType, int Size, object Value);

SqlParameter MakeOutParam(string ParamName, SqlDbType DbType, int Size);

SqlParameter MakeParam(string ParamName, SqlDbType DbType, Int32 Size, ParameterDirection Direction, object Value);

}

对于连接信息,如连接字符串不应在所有用到数据库的地方出现,负责在部署时不得不在所有的类中调整!所以把它方在XML配置文件中是明智的(分成集成和混合安全性),再用一个类管理它即可.

XML文件的内容:



<?xml version="1.0" standalone="yes" ?>

<NewDataSet>

<DBConfig>

<ServerName>Gaolei</ServerName>

<Machine>GAOLEI</Machine>

<DataBase>OA</DataBase>

</DBConfig>

<DBConfig>

<ServerName>Gaolei</ServerName>

<UID>sa</UID>

<PWD></PWD>

<Machine>Gaolei</Machine>

<DataBase>OA</DataBase>

</DBConfig>

<DBConfig>

<LogCount>100</LogCount>

</DBConfig>

</NewDataSet>。

对于数据实体层,它负责传递数据,是各层交换数据的地方。设计时应考虑这样几个因素:

第一:性能,交换数据的地方必须要求交换快、占内存少.

第二:业务规则类可以有效地使用他们。

第三:有利于界面部分使用它们,即要能和用户控件绑定在一起使用,帮助简化界面的开发。

为了满足第一要求,可以将实体的值域上移放在基类中,这样两个类为继承关系又各负各则。基类(数值类)的实例数与其子类(方法类)实例数不成比例,基类实例数总是大于方法实例数,一般是N:1,这样消除了没有必要的内存开支,大大提升了性能。对于有些方法参数列表太长,就可以使用基类对象代替。

方法类集成了常用的数据处理方法,所以一旦业务规则类使用它,可以大大简化规则类的复杂度,设计者可以集中精力设计规则类而不必同时考虑实体类的问题。由于值域上移,把值域做成属性,界面上的控件将天生支持对这些属性的绑定。(.net控件的特性)

实体类:

(数值类)

public class LogRow:MarshalByRefObject,IComparable

{

protected String m_OperateType;

public virtual String OperateType

{

get { return m_OperateType;}

set { m_OperateType=value;}

}

..........

public LogRow()

{// TODO: 在此处添加构造函数逻辑



}

#region IComparable 成员



public int CompareTo(object obj)

{

LogRow Row=(LogRow)obj;

if(Row.Operator.Equals(this.Operator)&&Row.OperateType.Equals(this.OperateType)&&Row.OperateTime.Equals(this.OperateTime)&&Row.Contents.Equals(this.Contents))

return 1;

return 0;

}



#endregion

}

方法类:

public class Log:LogRow

{

public Log()

{

}

public bool Create(String operateType,String contents,String Operator,System.DateTime operateTime)

{

Database data = new Database();

SqlParameter[] prams = {

data.MakeInParam("OperateType",System.Data.SqlDbType.VarChar,50,operateType),

data.MakeInParam("Contents",System.Data.SqlDbType.VarChar,255,contents),

data.MakeInParam("Operator",System.Data.SqlDbType.VarChar,50,Operator),

data.MakeInParam("OperateTime",System.Data.SqlDbType.DateTime,8,operateTime)

};

int reval = data.RunProc("Log_Create",prams);

data.Close();

data.Dispose();

if(reval==1)

{

return true;

}

else

{

return false;

}

}

public bool Create(LogRow LogObject)

{

return this.Create(LogObject.OperateType,LogObject.Contents,LogObject.Operator,LogObject.OperateTime);

}

public bool Delete(System.DateTime operateTime)

{

Database data = new Database();

SqlParameter[] prams = {

data.MakeInParam("OperateTime",System.Data.SqlDbType.DateTime,8,operateTime)

};

int reval = data.RunProc("Log_Delete",prams);

data.Close();

data.Dispose();

if(reval==1)

{

return true;

}

else

{

return false;

}

}

.......

}

2) 业务归则层:

要有自己独立的自定义异常类,对于业务方法要适当使用多线程提升性能。最好使用TeampleteMothed模式集成流程和适应未来的业务变化或者将方法设置成virtual!

public class OMManager

{

private User user;

private UserRole userRole;

private Role role;

private RolePopedom rolePopedom;

private string m_CurrentUserName;

private string m_CurrentPassWord;

public OMManager(string CurrentUserName,string CurrentUserEncryptedPassWord)

{



user=new User();

userRole=new UserRole();

role=new Role();

rolePopedom=new RolePopedom();

if((new SecurityValidate()).Validator(CurrentUserName,CurrentUserEncryptedPassWord))

{

this.m_CurrentUserName=CurrentUserName;

this.m_CurrentPassWord=CurrentUserEncryptedPassWord;

}

else

{

throw new SecurityException("无效用户名/密码");

}

}

public virtual string NewUser(UserRow NewUserData, string[] AssignedRoles)

{

string m_HashedPassWord=StringEncryptor.Encryptor(NewUserData.HashedPassWord);

NewUserData.HashedPassWord=m_HashedPassWord;

if(user.Create(NewUserData)&&userRole.Create(NewUserData.UserName,AssignedRoles))

{
//ToDoSomething
}

return null;

}

........}

3)Web界面层:要使用规则层的方法执行业务功能,但并不是什么都要通过规则层,而是数据需要业务处理的就引用规则层方法,如果业务上不需要处理(如:填充一个下拉列表)就可以直接使用数据访问层,这样可以减少没必要的性能开支。对于安全性,就是要使用规则类必须经过验证。对于性能可以使用ASP.Net的缓存技术解决


分享到
  • 微信分享
  • 新浪微博
  • QQ好友
  • QQ空间
点击: