文件名称：PetShop4.0宠物商店+系统架构设计+中文注释源码+PDF中文详解
文件大小：8.17MB
文件格式：RAR
更新时间：2015-09-17 05:56:41
PetShop4.0 宠物商店 系统架构设计 中文注释源码 PDF中文详解
一、Model主要功能： 1、 将每一个“业务实体”抽象成“（瘦数据）类”，可以很好地“划分”各个“对象”，操作更加清晰 2、 用于在应用程序各层之间传递数据，被用做传输数据的“容器” 3、 这就是所谓的“建模”过程！ 4、 Model各个类（Model文件夹中的各个文件）划分或者说编制的原则，更趋向于模拟整个系统中的业务实体 二、实现细节： 1、 PetShop中Model的规划与数据库表的关系： （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的类”所必须实现的一系列方法。（Item在Model中定义了，是指具体某一类别的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层分割BLL和DAL层的意义！！！） 2、 既然在实现GetItemsByProduct()方法的时候，也是要把返回的所有Item对象添加到一个ArrayList当中去，但为什么GetItemsByProduct()方法返回的不是一个ArrayList对象，而是一个IList接口的对象呢？仅仅是基类引用的方法吗？这里的基类引用有什么用呢？是否是由于为了不限制使用的数组形式？执行IList则可以使用ArrayList，也可以使用其他形式的数组？？？ 3、 IProduct.cs文件中为何要将查询条件参数定义为一个string类型的数组？