.net web 架构浅谈
让我们先看看经典的三层架构 ，然后讲讲各个层次的用处和特点
一般web应用程序包含下列层次
WebUI|WinUI|WebService:界面和webservice
Business Facade:业务层的包装
Business Rule:业务规则
DataAccess:数据访问
SystemFramework:框架,为上面的层提供一些公共的方法和工具类,比如配置文件,日志和缓存等等
Common:这是可选的,一般放层间传递的实体
一般网站的框架就从这里裁减出来,
从最上层开始说,webui,一般网站当然是少不了的,webservice就不一定了,如果你需要为合作伙伴提供服务,自然就可以保留,或者你决定采用smartclient(微软提出的基于webservice的客户服务模型),则必不可少,当然,还可以往里加入层次,比如微软的applicationblock就把ui分成了界面逻辑和实现,可以让不同类型的界面共享一个界面逻辑
业务层包括business Facade和BusinessRule,可能有些人会觉得多余,但实际上,facade是对业务层提供方法的一个包装,不管下面business rule怎么变化,这个层相对固定,而business Rule就是专门的业务逻辑了,如果没有复杂的业务逻辑判断,这两层可以合并,对中型网站来说,业务层用一层是可行的.
数据访问层不用解释太多,不过我解释下所谓IDataAccess接口,和DataAccessFactory的提法,实际是对上层提供一个统一的数据访问层接口,然后可以许多实现,比如针对sqlserver的实现,oracle的实现等等,于是可以实现数据库的切换,现在所谓的provider模式,见微软的dataaccess application block,就是这样一种实现,给出一个统一的接口,然后针对不同数据库写不同的实现,而且上层和数据访问层间是通过配置文件来连接的,于是可以实现动态切换,当然这是一个好办法,不过一般如果网站的数据库相对固定,(一般不会出先切换多种数据库的情况),就完全可以不用这样实现了.
common里面放业务实体,很多网站都是这样作的,但是当然也有局限性,因为一般common里放的是在层间传递数据的统一格式,也就是所有的层次都是由这个来传递数据.但有时候,各个层间可能需要不同数据传递格式.
中型网站,一般三层,一个界面层,一个业务层,一个数据访问层足够了,因为,除非是商务网站,一般业务逻辑不复杂,无外乎是一些有效性验证工作,这是两个业务层就多余了,winui,webservice一般可能不需要,数据库也不用切换.
systemframework,看起来是一个杂货铺,但其实是一个比较重要的程序集,他一般是许多次开发经验积累的结果,里面的日志类,缓存类,配置文件访问类,断言,还有测试工具,都可以被在许多网站中重复使用,所以一个好的框架集,简直就是一笔财富,开发的时候应该注意经常把好的东西,通用的东西放进来,然后用适当的命名空间加以分类,以后会收益无穷
开发过程和方法,是另外一个话题,但是既然提到了,我就简单说说,软件从需求分析,建立模型,到代码是一套流程,比较严格的方法是用rup,但是这个对前期需求要求比较清楚,计划制定与建立模型需要相当的时间和工作量,对于小项目,小团队,是得不偿失,而且rup重在从需求建立模型和架构,而网站开发的模型和架构都比较成熟,不用每次都从0开始,所以,简单一些,实用就好,可以考虑敏捷开发,这种开发速度较快,对不确定的需求支持好,讲究测试和重构,具体不详述,有兴趣参资料,一搜一把