PetShop3.x学习笔记11-BLL学习笔记

一、 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，要搞清楚含义及用法