NET网站系统开发实训 教学课件 作者 洪洲 电子课件 任务4：如何快速进行.NET网站系统建设.pptVIP

任务四 如何快速进行.NET网站系统建设 实用软件工程思想介绍 典型问题 太依赖调试工具，在真正的生产环境出了问题就不好办了 程序写得很长，阅读十分困难 比较少重构出好的抽象类，很多代码都大同小异 喜欢把应用跑起来检验程序的对错，浪费很多时间 对WEB应用运作的基理不太清楚，难以应对一些特别的要求 有效技术 借助单元测试工具，在集成前首先测试业务逻辑代码是否正确 利用强大的log4net日志功能，把详尽信息记录到文件中，便于出现问题后的分析 所有服务都是先确定接口再完成实现代码和单元测试 充分利用JSON数据包把前台界面和后台服务解耦，可以分开进行测试，从而大大降低集成测试花费的时间 三层框架连接协作图 原理说明 当我们按查询按钮时，系统就会向后台的入口网页：ProductPage.aspx传递下面的参数： s_method:’list’//表明需要列表查询 query:’ category=电视’//表明要查电视类产品 start:0//表明从第一条数据开始 limit:10//表明取回十条记录 三层框架WEB开发步骤 Data项目编写—目的 任何应用系统都需要为现有流程提供帮助，操作的结果是产生数据或者修改数据的状态。 有过开发经验的人都明白：企业是在竞争中生存的，企业的处理流程不是一成不变的，它会因为竞争对手或者内部改进而不定期变化，但是于流程和业务规则的变化相比起来，企业实体数据：比如客户资料，订单资料等则相对稳定的多。 我们编写数据定义项目，就是为前后台数据交换提供一个格式，另外也可以通过这些定义直接创建数据表到数据库中。 Data项目编写—作用 以前我们编写程序时一般会先设计数据表，手工或者用一些工具把数据结构创建好，通常我们就叫这样的一张表叫实体表，比如客户、订单、产品等。实际上这些实体数据之间是有关联的，比如一个客户会有很多订单，而一张订单里会有多个产品项等等，这就是所谓的实体之间的关系,过去也叫E-R模型。 关系有两种：一种称为一对多，另一种称为多对多。一对多很容易理解，比如订单里要包含客户的资料，那么我们就把客户的ID存放到订单表中。而多对多的关系就需要使用另外一张数据表来存放，比如用户所在的角色就这样的，里面就包含用户ID和角色ID。 在我们查询某些业务的时候，我们经常要看到相关的资料，比如看订单时也要看到客户的等级、电话等，而不是一个光的ID,所以这时候我们就需要另外一个有用的东西—视图，有了视图，我们就可以把这些资料拿出来，但是存放资料又不用到处重复保存。重复保存往往会带来更新后的不一致，给理解带来混乱。 Data项目编写—步骤 创建数据实体项目 名称：项目代码.Data Data项目编写—步骤 编写实体类 表实体命名名称：T+实体英文 视图实体命名名称：V+实体英文 Data项目编写—步骤 定义好数据后，我们就可以创建一个控制台应用程序来试验了，这个程序的名字通常是项目代号.App 我们可以数据库中先创建一个Demo数据库用于学习之用(可以检查一下数据表中的列名和实体对象属性之间的映射关系) 然后在App.config中定义该数据库连接 Service项目程序编写 –目的 提供灵活的数据查询处理能力 提供灵活的业务逻辑实现 Service项目程序编写 –作用 服务层主要需要解决的问题是将各种业务规则进行封装，通过接口的方式暴露给应用程序调用，如果应用程序客户端是远处的javascript编写的，那么通常还要编写一个门面程序(Facade)，扩展方法(Extend)去返回JSON格式的需要的数据包。 如果是关键型应用，则需要使用事务确保所有数据要么都提交，要么全部都不提交。 Service项目程序编写 –步骤 创建服务项目 名称：项目代码.Service Service项目程序编写 –步骤 编写服务接口 命名要求：I+实体英文+Mgr 比如：账户管理接口? IAccountMgr 存放子目录：service 编写服务实现 命名要求：实体英文+Mgr 比如：账户管理实现? AccountMgr 存放子目录：impl 编写查询实现 命名要求：实体英文+ Query 比如：客户查询? Customer Query 存放子目录：query Service项目程序编写 –步骤 编写前后台交换门面 命名要求：实体英文+ Facade 比如：书籍处理门面? BookFacade 存放子目录：facade Test项目程序编写 目的 验证业务逻辑是否符合预期要求，系统性能是否满足要求等。 操作步骤 创建测试项目 名称：项目代码.Test 比如项目代号为Start,则工程名为Start.Test,产生的组件名称是Start.Test.dll