一、 BLL主要功能:
1、 实现核心业务逻辑
2、 在PetShop中,BLL层执行最多的任务就是:
(1) 对用户输入(或调用时传入的参数)进行简单有效性校验
(2) 调用相应底层的方法(已建立好),完成操作,并接收返回值,返回给上层
二、 实现细节:
1、 Account.cs文件:进行用户输入信息的校验,如果不为空,则建立一个IAccount接口实例,调用底层的方法,传递用户输入的参数;接收返回结果,但不再对结果进行有效性校验,直接返回给上层调用程序
2、 校验用户输入是否为空的操作,本来在web层就可以完成,但为什么要放在BLL层?
3、 Item.cs文件:与Account类实现的功能和采用的方法基本一致
4、 Cart.cs / OrderInsert.cs / Cart.cs / CartController.cs(Web) / Item.cs文件:注意!这里的Cart是需要实例化的!!!是针对某个用户某次的购买行为的购物车!!!而保持用户状态似乎是在Web层完成的
5、 Cart类非常典型!!它不是基于某一张数据库表的,而在它当中定义的“方法”,需要对底层数据库的很多表进行操作,而对这些表的操作则已经分散组织在不同的类当中。只需要实例化相应的类,调用设计好的方法,就可以实现对某特定数据库表的操作。
6、 看到现在,所有的页面转向都使用了HttpContext.Current.Server.Transfer(TargetURL);
7、 注意看OrderInsert类!!!它继承于ServicedComponent基类,用于实现“分布式事务”
8、 Cart的内容看《相关资料1、2》即可。基本看懂。待练习。
9、 Inventory.cs文件:实现对库存某Item的数量进行读取和修改的方法。可针对某张订单,对相应的Item减少库存数量
10、 OrderRead.cs文件:根据传入的一个OrderId参数,返回一个OrderInfo实例
11、 Product.cs文件:校验传入参数;调用底层方法
12、 Profile.cs文件:校验传入参数;调用底层方法
三、 启发:
1、 使用VS进行开发的时候,如果选定了数据源,则自动生成对应数据库表结构和字段类型的“强类型DataSet”!又因为强类型DataSet可以用做Model的功用,在BLL和DAL之间传递数据,则是否可以使用这样的VS自生成的“强类型DataSet”代替系统中对Model的设计???“强类型DataSet”和Model都是面向数据库表,以数据库表为基础的!!!要知道,当数据库表结构更改了之后,VS会自动重新生成“强类型DataSet”,而这就省去手工修改Model定义的步骤了!!!
2、 在BLL和DAL之间传递的数据,可以是:
(1) 基本类型的数组(如int数组)
(2) 对象的集合。如Customers集合,里面使用一个ArrayList实现
(3) 原始的DataSet
(4) 强类型DataSet
3、 分层系统的设计过程,是否为:
(1) 建立Use Case图
(2) Model规划
(3) 数据库建模
(4) 类设计
4、 数据库表(数据库架构)的规划和(字段)设计似乎都是根据业务实体,也就是Model来进行的。可以看到,在MSPetShop数据库中,每张表都对应了一个业务实体!!!
5、 从不同层中的Account类所完成的不同任务,思考系统分层设计的原则:
序号 | 所在层次 | 完成任务(功能) |
1 | Model / AccountInfo | 1、 定义业务实体Account 2、 定义实体的各属性,并提供读取和修改属性的方法 |
2 | IDAL / IAccount | 1、 定义AccountDAL必须执行一系列方法,这些方法用于对用户的Account进行操作 |
3 | SQLServer / Account | 1、 实现了IDAL/IAccount定义的一系列数据库访问方法,用于对用户的Account进行操作 2、 具体为(1)编制SQL语句模板(2)根据调用此方法时提供的参数,获得SQL语句参数数组(3)构建SQL语句(4)使用SQLHelper执行SQL语句(5)返回调用结果 |
4 | DALFactory / Account | 1、 从配置文件中读取“在对用户Account进行操作时所使用的适当的DAL层”标识 2、 使用反射,动态加载“适当的DAL层组件”,并创建对用户Account进行操作的类的实例,给BLL层返回IAccount接口 |
5 | BLL/Account | 1、 进行用户输入的校验(是否在Web层就可直接完成?)。有可能是因为针对用户账户的业务逻辑仅涉及到是否为空? 2、 根据希望进行的操作调用底层方法(不同的方法完成不同的操作)。并将用户输入的有效信息作为参数,传递给底层方法 3、 接收返回值(并不做返回值在逻辑上是否正确的交验),反馈给调用程序 |
6、 某个类要实现的功能是用“方法”来进行定义的;每个“方法”都可以抽象为“对数据库进行的一些操作”;对某个数据库表进行“增删改查”操作的所有方法应该已经在某个类当中被组织起来了;在需要对相关数据库表进行操作时,实例化这个类,调用相应方法即可,不需要重新实现和底层的交互过程
7、 似乎在设计完实体和数据库表之后(形成了Typed DataSet),如果要再继续开始设计底层(DAL层 / IDAL层)对数据库表进行操作的各个方法,是缺乏依据的,因为我们无法确定需要对数据库表进行的操作(体现为IDAL层定义的方法),也无法确定上层的处理和展现需要那些类型的返回值。这时候,似乎应该从上层开始工作了!根据Use Case过程定义(?),建立每个页面,确定每个页面需要的功能。然后根据这些功能,确定需要对数据库做哪些操作。继而可以设计IDAL层,设计DAL层
四、 问题:
1、 如何从“过程”中抽象出“业务实体”?是有一定的规定和方法,还是全凭经验呢??
2、 在架构设计的时候,是应该先设计底层DAL、IDAL和DALFactory呢,还是应该先设计Web,根据Web的需求(对于所需数据库操作和返回值类型)设计底层?
3、 OrderInsert.cs文件,其中涉及一些分布式事务的内容,还有一些特殊的Attribute,要搞清楚含义及用法