多层应用程序的开发

商业应用程序一般会有多层

表现层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的模式发生了改变，你必须重新建立强类型，这时将失去商务逻辑。