本章我们来看一个经典的订单应用程序“OrderIT”，它管理产品、订单、顾客的信息等。
需求分析
1.存储客户的信息。每个顾客都有名字、账单地址、送货地址。地址不是单纯的文本，而是由街道、城市、邮政编码、国家组成的。更重要的是，顾客可以访问Web服务添加和更新订单，所以需要一个用户名和密码访问Web服务。
2.存储供应商的信息。每个供应商都有名字、国际银行帐户号码（IBAN）、顾客付款条款（顾客支付发票的天数）。
3.存储产品信息。系统必须能出售任何的产品，从鞋子到衬衫，从电脑到乒乓球拍等。而且应用程序可以方便添加新产品而不对之前的产品和有关的订单产生影响。
4.追踪当前的库存量。出售产品和进货都要更新库存量，用户还可以添加新的产品到当前数量。
5.存储供应商出售的任何产品。一个供应商可以卖很多产品，一种产品也可以从很多供应商处购买。
6.管理顾客的订单。每个订单必须存储是谁下的订单，顾客可以选择存储在数据库中的送货地址。顾客一次可以买很多产品，所以一个订单包含多个详细信息。
7.计算适用的折扣。折扣政策规定，如果客户购买超过5件相同的产品，其后的每件产品有10％的折扣。如果适用折扣，订单必须包含两个细节：第一个是包含前五个没有折扣产品的信息，第二个是包含其他折扣的产品和相关的折扣信息。
8.允许用户方便快捷的修改产品价格。有时候用户需要修改一种产品的价格，有时候需要根据特征更新价格（如产品类型或者品牌）。
9.允许顾客查看和修改账户的详细资料和订单。OrderIT公开一个Web服务，顾客可以使用它添加，更新和删除订单，还可以修改修改自己的账户信息。
以上的需求分析如下图所示：
设计OrderIT的模型和数据库
在开始之前，先说一下“自底向上（Bottom-up）”和“自上而下（top-down）”的设计方法。
开始设计一个应用程序之前，你必须确定先创建什么：数据库还是对象模型。
先设计数据库是自底向上的方法，它最常用有两个原因：第一，以数据为核心的应用程序。第二，在微软堆栈（Microsoft stack）中面向对象的设计相对是一项新技术，所以在数据库设计之前设计模型还不是太普遍。其他的，数据库管理员拥有很大的决定权，尤其是在存储有大量数据的大公司，数据库管理员往往先考虑数据库。“自底向上”的设计保证了最好的性能和存储优化，如果数据库管理员工作的好，你可能只需要利用存储过程与数据库交互二隐藏了底层的数据库结构。另一方面，这种方法意味着是根据数据库的需要组织数据，数据被分割很难被应用程序使用。
先设计对象模型是自上而下的方法。自上而下的主要优势是应用程序几乎独立于数据库塑造它的模型。弊端是有时候可能不利于数据库的组织，也有可能损失性能。
数据库是应用程序的重要组成部分，所以应该模型设计和数据库设计无缝的组合在一起，这样才能更好地使用它们。自上而下的设计把重点放在了模型和业务上，而不是数据组织上，但是如果它影响了数据库的性能应该放弃它而使用自底向上的方法。我们认为，“自上而下”的设计是最好的方法，在实际项目中可以从这种方法中获得很大的益处，并且数据库性能也很好。尽管现在“自底向上”的方法仍然很普遍，但是“自上而下”的设计方法越来越受到欢迎。
Entity Framework设计器可以允许采用以上两种方式。你可以可视化的设计模型类，然后让设计器产生映射信息和数据库脚本（top-down, model-first），你也可以导入数据库，让设计器产生类，并且和数据库表一对一映射（bottom-up, database-first）。
顾客（Customer）和供应商（Supplier）类
顾客有账单地址和送货地址，订单有送货地址，所以先创建一个AddressInfo的复杂类型。然后创建一个名为Company的抽象类，让Customer和Supplier类继承自Company。设计数据库时创建一个Company表，将Customer和Supplier需要的字段都放到Company表中，此外，添加一个Type列，用于指定一行是属于Customer还是Supplier。主键是CompanyId，自动增长。如下图，左边是Company表，右边是它的继承层次结构。
产品（Product）类
创建一个Product基类，然后为每一种产品创建一个类，让它们都继承自Product类。设计数据库时创建一个Product表，包含所有产品的公共信息，然后再为每一种产品创建一个表。例如，Shirt表和Shoe表。所有表的主键都是ProductId，在Product表中是标识列，其他表中不是。为了正确的关联记录，在Product表中的主键必须与子表中的主键相匹配。下图展示了表和模型类的结构：
根据OrderIT的需求，必须对每一个供应商提供的产品的销售情况进行追踪，因为一个产品可以由多个供应商提供，一个供应商可以提供多种产品，所以它们之间是多对多的关系。在关系模型中，为Product类中添加一个类型为ICollection<Supplier>的Suppliers属性，为Supplier类中添加一个类型为ICollection<Product>Products属性。在数据库中可能有点困难，那你不能对子表添加外键，因为根本就没有子表。唯一的方式就是添加第三个表，叫ProductSupplier，它包含Product和Supplier的Id，它们共同组成ProductSupplier的主键。如下图：
订单（Orders）类
在模型中，创建一个Order和OrderDetail类，第一个包含订单信息，第二个包含了它的详细信息。因为用户可以选择存储在顾客账户中的送货地址，所以在Order中添加一个ShippingAddress属性。关于关系，在Order类中添加一个导航属性OrderDetails，在OrderDetail中添加一个导航属性Order。一个订单必须有一个顾客，所以Order类中必须有一个Customer的导航属性。每个订单详细信息里包含一件产品，所以在OrderDetail类中添加一个Product导航属性。
在数据库中，为所有的订单创建一个Order表，为所有的详细信息创建另一个OrderDetail表，主键是标识列，Order表包含地址信息。当设计到表之间的关系，必须添加以下外键：
(1).Order表的CustomerId——链接订单和顾客。
(2).OrderDetail表的OrderId——链接订单和它的详细信息。
(3).OrderDetail表的ProductId——链接订单详细信息和产品。
写在后面的话
需求分析和模型和数据库都设计好了，下一篇进行实际的操作。