商业应用程序一般会有多层
表现层presentation，商务逻辑层business，数据访问层data access和数据存储data store
分离逻辑思维的需要，团队或多语言开发的需要，重用商务逻辑层与数据层的需要
BT层：整体设计，安全性，商务规则，数据校验处理
面向对象编程OOP
完全OOP：任何事物都是对象，大概会有1000多个对象存储在RAM中
例如：Customers,products,Orders,Addresses,…
OOP的巨大能量能处理任何的问题，但也带来一定的压力。
大颗粒（large-grain）OOP：任何对象都是对象，但对象是大颗粒的。
少量的全面的对象，虽然不优雅，但是更实际。
不使用OOP：没有对象--返回过程样式的编程。
没有类--基于结构和静态方法。
大颗粒设计，我们不要把所以的customers 都存储在RAM中。
通过ID获得唯一的customer,可以查找customer ID的子集。
安全性
安全性非常的复杂，对于任何一层的设计都有潜在的影响
谁将使用本系统？（验证）
是否允许该用户进行此操作？（权限）
在何处进行安全检查？
商务逻辑层
表现层是否需要反映出用户的权限？
数据层是否需要进行检查？
最基本的是通过商务规则来进行检验
商务规则
典型地通过明确地编码表现
不同的商务情况有不同的规则
但，有一条通用的规则-校验 validation
校验（validation）
表现层是第一级检验
例：整形输入
典型情况，BT再做一次额外的检验。ID号码/信用卡号码/e-mail地址等是否有效
编写有力的代码控制，正则表达式（regular erpressions）
正则表达式REs，是强大的检验技术
过程：有效的输入被表现为一种模式，对于用户的输入，运行模式进行检验。
例如：“d”指单一的数字{0,1,2,3,4,5,6,7,8,9} “w+@w+”是一个简单的E-mail地址模式
例：检验Zipcode是否符合US的标准
Zip 或 Zip+4
模式：^表示开始，？可选，$结束
防止SQL输入攻击
在数据被传入到数据层之前，对于文本框的内容必须检验。
在数据访问层并不管理和存储数据，它只是提供商务逻辑层和数据库之间的接口。
设计接口，主要考虑到问题：high-level 还是low-level接口？存储过程或者动态SQL语句？
HL接口隐藏BT传来的细节信息
LL接口
存储过程
create proceduer sproctopten
as set rowcount 10
select * from customers order by accountBalance Desc
存储过程是存储到数据库的SQL语句
DBAs编写，数据库模式与应用程序分离，提供数据访问控制的另一层，封装复杂的SQL，保证事物执行，可能对提高性能产生很大的帮助。
执行存储过程
使用标准的ADO.NET机制来执行
例如：获取前10名最高账户余额的客户，通过ID删选客户信息
层间如何传递数据：
基本类型的数组，对象的集合，原始的dataset,强类型dataset
强类型datasets，是特殊化的dataset
强类型dataset 是从dataset继承的定制对象，它可以通过其显露的属性（properties）来对封装数据进行强类型的访问。
强类型dataset避免了字段的晚绑定。强类型dataset提供了强类型的访问器，因为避免了到一个集合中查找列名或表名，访问时更快。
除了能够提高运行时的性能，强类型dataset还提供了类型检查，并且在设计时可以通过自定义字段名对字段智能感知。
例：
如何建立强类型（方便的，面向对象的，且易建立的）
强类型dataset可以当作BT，建立强类型dataset，添加一些实现商务逻辑的方法
如果DB的模式发生了改变，你必须重新建立强类型，这时将失去商务逻辑。