PetShop学习笔记

一、Model主要功能:

1、              将每一个“业务实体”抽象成“(瘦数据)类”,可以很好地“划分”各个“对象”,操作更加清晰

2、              用于在应用程序各层之间传递数据,被用做传输数据的“容器”

3、              这就是所谓的“建模”过程!

4、              Model各个类(Model文件夹中的各个文件)划分或者说编制的原则,更趋向于模拟整个系统中的业务实体

 

二、实现细节:

1、              PetShopModel的规划与数据库表的关系:

(1)        AccountInfo类——Account

(2)        AddressInfo类——无直接对应关系(对应Account表中一部分字段)

(3)        CartItemInfo类——无直接对应关系

(4)        CreditCardInfo类——无直接对应关系

(5)        ItemInfo类——Item

(6)        LineItemInfo类——无直接对应关系

(7)        OrderInfo类——Orders

(8)        ProductInfo类——Product

2、              为每一个Model中的类都标记了[Serializable],说明这些类可以被传行化,但是不能被继承!

3、              AccountInfo.cs文件:用户在网站注册的信息,及喜好选择情况

4、              使用构造函数可以初始化私有字段;使用属性可以读取私有字段(但使用属性不能设置私有字段的值)

5、              其中包含一个AddressInfo类的私有变量,和一个AddressInfo类的属性

6、              命名空间为PetShop.Model

7、              AddressInfo.cs文件:用户真实的个人姓名、住址和电话号码等信息

8、              AccountInfo不同的是,AddressInfo类允许使用属性设置私有变量的值

9、              CartItemInfo.cs文件:描述购物车中每一种所选商品的信息的类

10、          该“类”对象的某些信息(如这里的Subtotal属性)可能并不是此类的“自然信息”,而需要经过简单计算而得到!这些简单但必要的信息也要在类的设计中体现出来!

11、          CreditCardInfo.cs文件:表示特定一张信用卡的信息

12、          ItemInfo.cs文件:一个Item指的是category"product"item,如猫"波斯猫"成年男波斯猫(或成年女波斯猫)。这个文件表示一个Item的所有信息

13、          productDesc字段的作用?

14、          LineItemInfo.cs文件:注意与CartItemInfo类的区别!LineItemInfo是用来描述用户最终确认的订单当中的某一种类的产品的信息的类

15、          同样包括了Subtotal属性

16、          OrderInfo.cs文件:用于显示用户某一个订单具体信息的类,在此一个订单当中,可能包括多个商品种类,即包括多个LineItemInfo对象(实际上在OrderInfo类中也确实存在LineItemInfo类型对象的一个数组!)

17、          ProductInfo.cs文件:包括一个特定Product的信息,如波斯猫

三、启发:

1、              来自Directory项目结束后的启发,以后做设计的时候,要将每个实体抽象为一个类,在整个系统中进行操作。

2、              在任意一个类当中,可能不只包括此实体类的自然信息,也可以包括一些对其他地方数据调用有用的属性信息,如根据数量和单价计算出来的总价属性,或者标志此实体的直属上级实体的属性

 

四、问题:

1、              忽然发现在MSDN上有文章,关于数据实体的:浏览

2、              抽象这些业务实体模型为瘦数据类的原则是什么?什么样的业务实体可以被抽象,或者说进行抽象后更有意义?

3、              ItemInfo类中,productDesc字段的作用?

 




一、IDAL主要功能:

1、              这完全是工厂模式的一部分实现而已

2、              这是一组接口类,其中包括了每个要公开的数据访问方法。为每个数据库产品单独编写的DAL(数据访问层)都要实现这组接口所定义的方法

3、              也就是规定了在DAL中编写的对用户账号进行操作的类所必须执行的方法!

4、              IDAL要达到的目的是:实现业务逻辑(BLL)与数据库访问(DAL)的完全分离!!!

5、              IDAL各个类(IDAL文件夹中的各个文件)划分或者说编制的原则,更趋向于将对数据库的不同操作进行归类,考虑的主要方面是数据库操作!!!例如,有对用户账号进行的一系列数据库操作,则将这一系列操作统一放置于IAccount接口(将来实现后的Account类)文件当中

 

二、实现细节:

1、              IAccount.cs文件:为针对不同数据库产品编写的操作用户账号的类所必须实现的一系列方法定义契约

2、              IInventory.cs文件:定义操作库存量的类所必须实现的一系列方法;或者说将操作库存量的一系列(所有)方法做一个汇总

3、              IItem.cs文件:定义操作某一Item的类所必须实现的一系列方法。(ItemModel中定义了,是指具体某一类别的Product,如男猫或女猫)

4、              对于其中的GetItemsByProduct()方法,返回的是一个ArrayList的接口类型(IList)的对象(见问题部分!)

5、              IOrder.cs文件:定义了一组DAL层中操作用户订单的类必须执行的方法。其中包括添加一张新订单的方法Insert()和根据一个已有的订单号取得此订单详细信息的方法GetOrder(),此方法返回的是一个OrderInfo对象。(Model中的OrderInfo类模型定义了用户的某一张Order中相关的信息,如发货地点,总价,信用卡号码等等)

6、              IProduct.cs文件:定义类一组在DAL层中编写的Product进行操作的类

7、              IProfile.cs文件:定义一组在DAL层编写的“对用户Profile进行操作的类”

三、启发:

1、              这样就可以让在BLL层只针对IDAL层定义的接口进行编程(使用IDAL接口定义的这些方法)就可以了!!!无论在底层使用了什么厂家的数据库产品,有区别的只是针对此数据库产品编写的DAL层(相同的方法,如SignIn()方法,对于不同的数据库产品,可能有不同的实现方式!),而不会影响到上层的BLL层已经编写好的内容!

2、              从这里可以看到软件架构师和程序员工作上的区别!架构师要负责的是搭建系统的层次结构,定义接口;而程序员要负责的是针对接口的具体代码实现过程!

3、              这个IDAL接口的使用,主要是为了保证在底层数据库实现,甚至数据库产品发生变化的时候,不需要对上层BLL层的业务逻辑进行大量的修改!BLL层针对IDAL接口编程即可!!!

4、              IDAL文件夹中定义的所有的接口中的所有的方法,包括了整个程序要对数据库进行操作的所有方法

5、              由于PetShop只是一个演示程序,所以若对数据库操作的某一类别(如对Account进行操作)中定义的操作类不够用(如除了接口中定义的几个方法外还需要其他Account操作),还可以在接口中追加其他的方法,用以约束DAL层的实现类(如Account类)必须执行这些新增加的方法!

 

四、问题:

1、              定义这组接口后,如何保证为每个单独的数据库产品编写的DAL都执行这组接口所定义的方法?(答案:编写DAL的时候必须刻意保证,否则就失去了定义IDAL层分割BLLDAL层的意义!!!)

2、              既然在实现GetItemsByProduct()方法的时候,也是要把返回的所有Item对象添加到一个ArrayList当中去,但为什么GetItemsByProduct()方法返回的不是一个ArrayList对象,而是一个IList接口的对象呢?仅仅是基类引用的方法吗?这里的基类引用有什么用呢?是否是由于为了不限制使用的数组形式?执行IList则可以使用ArrayList,也可以使用其他形式的数组???

3、              IProduct.cs文件中为何要将查询条件参数定义为一个string类型的数组?

 

你可能感兴趣的:(学习笔记)