分享
 
 
 

架构设计之首部曲

王朝other·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

系统采用|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的缓存技术解决

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有