|
|
|
|
你现在的位置：您现在的位置是: 中国ASP>>ASP教程>>asp类 |
|
| 我眼中的ASP新框架 |
|
必定是基于三层结构开发
数据库层
业务逻辑层
用户UI层
一，数据库层
使用中等规模以上的关系数据库、对象数据库，在项目开发中针对客户需求采用大量的存储过程、触发器，在进行项目需求调研结果的第一步就是确定数据库结构，主要方法是：客户需求能否满足－－进行数据库范式化－－性能是否受影响－－进行数据库非范式化。
对于一个中大型项目来说，数据库设计的规范、健壮与否，对整个项目有着深远的影响，所以，我建议采用程序语言中的数据类型命名方法，来对数据库的字段进行命名例如：char字段，当然是String型，可以用s前缀，或者用Str前缀，俺本人一般使用后者，当然，这个必须根据所在开发组已经约定的格式进行，这种方法给后续的开发者以极大的方便，特别是一些梯度开发的项目，有几批人是分次加入进来的，每次都必须进行讲解和分析，那是重复性非常大的工作啊……
关于存储过程、触发器，在进行数据库设计的时候已经明确了的任务，比如有几个内联统计的，就应该马上编写相应的存储过程，并且列入数据库开发手册中，如果等到开发业务逻辑时再进行编写，就可能会出现一大批人在等一个人工作的情况……
此部分欢迎指正……
二、业务逻辑层
后台采用COM+，为了安全和稳定性，当然代码安全是第一步的，其次是数据库安全，数据库被爆库，多关是因为代码涉露了数据库的IP、User、PassWord，所以后台的业务逻辑交给已经编译成DLL的COM+组件是非常明智的。
关于业务逻辑层的分层，一般我这样认为：
1；数据库交互层（负责所有跟数据库打的交道），开发期由于编译成组件将导致开发过程极不连贯（因为要经常改动），所以建议暂时先编写成一个VBS CLASS进行封装，在后台开发完毕后再转成一个封装成COM+组件。
2；数据控制层：所有用户提交的数据全都交给控制层处理，比如FORM数据或者是URL参数，后台逻辑层的其它相关处理都必须从控制层获取返回值，这里应该进行的操作一般有：获取Request数据－－进行安全处理－－检查用户数据是否规范－－输出返回值。
3；权限控制层：至少要支持用户角色，再退一万步来讲，也要支持用户分组，这是基本到几乎等于无的东西，俺的要求一般是用户分组＋用户角色，如果项目不大，二层的用户角色应该就够用了，如果是大型项目，那就可能用到N级可继承的用户角色（可以用Windows中的用户组跟用户进行想象，Windows中的是二层的用户角色，角色间是不能继承的，角色只能继承用户组的属性），这个问题要讲清楚可能是另一个宏大的工程了，这里暂且打住。
4；业务层：建议把相关性的业务活动封装成一个个的VBS CLASS。比如要求制作一个内部的调货平台，那么就必然有入库、出库、分仓库存、汇总等操作，那么把这些跟仓库相关的操作都整理成一个CLASS，再从CLASS内部去调用上面提到的数据库处理层那些去协同处理仓库相关的操作。
对于核心业务层，一般都要求编译成DLL组件，为了安全，也为了开发公司的安全。
三、用户UI层
基本是以JavaScript为主，目前更倾向于JavsScript+XML这样的方式。为什么不采用VBScript，因为浏览器的支持问题。
一般俺分成如下三个部分
1；后台UI层：用于处理后台相关的数据显示以及进行风格控制，基本上后台风格更加统一，把显示处理进行最大规模的JS封装，可以减少后台开发的时间，让后台的程序员把尽可能多的精力用在业务逻辑的开发上，而不是忙于做后台的各种表格、表单、统计报表的显示。
2；前台UI层：跟后台UI层类似，为什么单独提出来，因为就俺接手的项目而言，前台非常少，主要都专注于后台，除了少数一些公众项目带有大量前台的。由于前台显示风格比较多变，因而统一性处理的可能性大大降低，建议使用比较成熟的UI框架进行开发，对于大型项目，应采用轻量级框架，JSVM2是一个不错的选择，唯一的缺点是目前文档少，对于不熟悉JavaScript的人是一大挑战。
3；数据传递层：负责预处理用户提交的所有数据，也负责接收后台输出的轻量级数据，比如，采用JSAX技术获取局部资料等
其实，对于前台开发一直不是俺工作的重点，所以可供整理的也少，这一部分，更是需要各位指正。
二○○六年二月二十五日
By 江一
|
|
|
