更新的BizObject.cst
前提：
1、建立数据库的各个表，最好以复数形式给表命名，字段名不要与表名相同。
2、设定表的主键。
3、设定表的外键。
4、建立表的索引。

主要特点：
1、支持一对多和多对一关系。
2、支持like查询。

用法：
1、完成"前提"中提到的各步。
2、用AllStoredProcedures.cst生成所有存储过程
3、用Model\Bulk.cst生成所有文件

不足：
1、刚建立，还没来的及详细测试。
2、可能会出现相同功能的存储过程，删掉其中一个就可以了，下一个版本计划修正这个问题。
(里面虽然有制作自己的EnterpriseLibrary应用程序块的模板但没有内容，过段时间在给出)

大家有什么好的架构，我可以帮着建立模板，同时希望对我建立的这个模板提出更多的意见。

这几天在看EDRA、GBI和WS-I Basic Security Profile Sample Application，有兴趣的共同学习。

idior的O/R Mapping 基本概念和一个困扰我长时间的问题也谈到了Entity和Domain Object

三、Biz Object
个人理解Biz Object更加专注于业务实现，主要强调业务类之间的关系。这也是它与Entity或Domain Object的不同之处。
在具体的程序中有时还会有Manager类，用于管理Biz Object和作为Biz Object的Facade。

我一直没有成型的架构，下一步抽时间看看Domain Model 探索和EDRA，我更觉得架构不用通用，可以根据一些典型的业务建立合适的架构，更希望大家能给出好的架构。

缓存应用程序块
1、简介
我们知道，在Asp.net中有个System.Web.Caching名称空间，但在Windows Form中却没有System.Windows.Forms.Caching名称空间，当我们在WinForm程序中使用缓存时，往往会引用System.Web.Caching名称空间，用其缓存机制来解决缓存问题。但用起来毕竟感到有些别扭，缓存应用程序块应运而生，但其更大的作用在于Smart Client程序中缓存本地数据到数据库或其他存储位置。缓存应用程序块比起System.Web.Caching名称空间来有更好的一致性和扩展性，同时能满足WinForm应用程序、基于WinForm的Smart Client、Web等应用程序的缓存机制。如果在web程序中使用缓存，System.Web.Caching足以应付，关键是开发者要有意识的去使用，并灵活运用它。如果想使程序的缓存机制具有一致的策略、更加简洁的调用方法、更好的扩展性，还是要用缓存应用程序块。
在日常编程中，我们往往会由这样的需求：
1、 我们不断重复地使用相同的一组数据，这组数据来源于持久化设备，读取时要花费一定的资源和时间，我们希望获取数据之后缓存于本地，下一次读取时直接从本地内存中读取。
2、 我们希望离线的使用一组数据，这组数据从数据源(网络、数据库、Webservices等)得到后要持久化到本地，下一次读取时避免重新从数据源读取。
3、 当应用程序的客户端数目加大、数据吞吐量变大时，程序还能保持很好的性能，即程序有可扩展性。
4、 我们缓存的数据要及时更新，以便与数据源保持一致。
缓存应用程序块就是基于此目的设计的，其主要特点是：
1、 可以应用于各类应用程序。如WinForm应用程序、Smart Client、Web应用程序、Enterprise Services等。也可以应用到程序架构的不同Layer上。
2、 灵活可变的缓存Storage选择。支持isolated storage、Database、内存，而且可以无缝的切换。
3、 修改缓存策略时，不用修改源代码。
4、 支持过期后，自动删除策略。支持基于时间的过期设置，也支持基于文件变化的过期设置。如果用基于时间的过期策略，则可以是绝对时间、相对时间、自定义格式的时间等。
2、使用步骤
①用配置控制台添加缓存应用程序块。
添加步骤同其他应用程序块。
当使用基于内存的缓存策略时，有几个参数要设置，其中ExpirationPollFrequencyInSecond是指过期轮询周期，就是多长时间就检查一下有哪些缓存项过期了，由后台独立进程执行。这个参数很关键，如果时间设置的太短，就会使这个后台进程不断执行，占用大量CPU时间，如果太长，又会浪费内存，要找个不长不短的，因此推荐用性能计数器监测一下，选一个适中的参数。
添加完毕后，默认支持基于内存的缓存，你还可以添加多个缓存管理器Cache Manager，以使用不同的缓存策略。
②写代码添加缓存项
// 最简单的添加缓存项：这是最简单的一种，我们也最常用，直接建立默认的Cache Manager
CacheManager cacheManager = CacheFactory.GetCacheManager();
cacheManager.Add("key", myObject);
// 创建指定的Cache Manager
CacheManager cacheManager = CacheFactory.GetCacheManager("Custom Manager");
cacheManager.Add("key", myObject);
// 基于绝对过期时间的缓存
// 过期是指当到了指定时间后，系统会将此缓存项清除掉，如果你再次访问的话，会重建。
CacheManager isolatedCacheManager = CacheFactory.GetCacheManager("Isolated Cache Manager");
DateTime refreshTime = new DateTime(2005, 7, 28, 17, 10, 10);

AbsoluteTime expireTime = new AbsoluteTime(refreshTime);

isolatedCacheManager.Add("myKey",dataSet, CacheItemPriority.Normal, null, expireTime);
// 注意上面这个例句是Isolated Storage基于隔离缓存的，可以看出Client代码的写法与用内存、数据库来缓存的代码完全一样，这保证了当你的缓存策略发生改变时，Client代码不用作任何修改。
// 相对过期时间的缓存
TimeSpan timeSpan = new TimeSpan(0, 10, 0);
SlidingTime expireTime = new SlidingTime(timeSpan);

cacheManager.Add("myKey1", cachedObject, CacheItemPriority.Normal,  null, expireTime);
CacheManager有只有两个重载的Add方法，其Sign如下：
public void Add(string key, object value);
public void Add(string key, object value, CacheItemPriority scavengingPriority, ICacheItemRefreshAction refreshAction, params ICacheItemExpiration[] expirations);
// 自定义格式的过期设置
// 格式为：<Minute> <Hour> <Day of month> <Month> <Day of week>
// 如：3 * * * *表示每小时的第3分钟就过期
//     * 1 * * *表示每天凌晨1点的每分钟
//     15 2 * * *表示每天2点15都会过期
ExtendedFormatTime expireTime = new ExtendedFormatTime("0 1 * * 5");
cacheManager.Add("key", cachedObject, CacheItemPriority.Normal, null, expireTime);

// 依赖于文件的过期机制
FileDependency expireNotice = new FileDependency("文件名");
productsCache.Add("key", cachedObject, CacheItemPriority.Normal, null, expireNotice);
缓存应用程序块还提供了过期提醒机制，不过这要实现ICacheItemRefreshAction接口，用于过期时执行一些自定义的操作，比如提醒。
③写代码读取缓存项
这个与我们以往System.Web.Caching的用法基本一致。
public BizEntry ReadBizEntryByID(string bizEntryKey)
{
 BizEntry bizEntry = (Product)cache.GetData(bizEntryKey);
 if (bizEntry == null)
 {
  // 这里如果被执行说明缓存缓存中没有
// 此处的正常代码逻辑是先建立一个BizEntry对象
// 再将这个BizEntry对象放到缓存中，当然也可以不放进去
 }
}
这里用的是CacheManager的GetData()方法：public object GetData(string key);
注意这里要进行强制类型转换。
BizEntry bizEntry = (Product)cache.GetData(bizEntryKey);
或者
BizEntry bizEntry = cache.GetData(bizEntryKey) as BizEntry;

  加密应用程序块

1、概述

当在不安全信道上传递一些敏感数据时，要对这些数据采取保护措施，即便是被人截获也难以从中得到所携带的信息，当我们保存一些敏感数据到物理设备时。也需要先将这些数据加密。

在对数据加密时，对于不同的场景采用的加密方式是不同的，一般来说常用的数据加密方式有三种。

²        私钥加密：私钥加密算法使用单个私钥来加密和解密数据。由于具有密钥的任意一方都可以使用该密钥解密数据，因此必须保护密钥不被未经授权的代理得到。私钥加密又称为对称加密或单钥加密，因为同一密钥既用于加密又用于解密。私钥加密算法非常快（与公钥算法相比），特别适用于对较大的数据流执行加密转换。一般情况下，对正式数据的传送中，一般先用公钥传送对称密钥，再用这个对称密钥加密要传送的数据。私钥加密的关键是如何保护对称密钥。

²        公钥加密：公钥加密使用一个必须对未经授权的用户保密的私钥和一个可以对任何人公开的公钥。公钥和私钥都在数学上相关联；用公钥加密的数据只能用私钥解密，而用私钥签名的数据只能用公钥验证。公钥可以提供给任何人；公钥用于对要发送到私钥持有者的数据进行加密。两个密钥对于通信会话都是唯一的。公钥加密算法也称为不对称算法，原因是需要用一个密钥加密数据而需要用另一个密钥来解密数据。它只可以加密少量数据。公钥加密一般用于交换私钥加密的私钥、对摘要进行签名等。

单向哈希加密：哈希算法将任意长度的二进制值映射为固定长度的较小二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。如果散列一段明文而且哪怕只更改该段落的一个字母，随后的哈希计算都将产生不同的值。要找到散列为同一个值的两个不同的输入，在计算上是不可能的。注意当用哈希算法对消息进行散列后是不能解密的，只能对同样的消息用同样的哈希算法加密，对照加密后的值是否一致，从而判断消息是否被篡改。哈希加密主要用于密码验证、身份验证、数据完整性等方面。比如数字签名的基本原理如下：

 

可以看出，数字签名不是一种具体的技术实现，它是基于以上各种加密技术组合的一种数据验证解决方案。

我们在配置应用程序块中已说明如何将配置数据加密，其他应用程序块的加密方式也相同，一般数据和配置应用程序块的配置数据我们会加密。比较理想的做法是用配置控制台将配置文件加密时，用DPAPI Provider ，这样我们就不用保存对称密钥了，系统会自动管理，这样数据加密就完全透明了，无需我们任何干预。

2、使用步骤

⑴用配置控制台添加加密应用程序块

跟前面的配置方法一致，添加加密应用程序块后，会有两个节点Hash Provider和Symmetric Provider，没有提供Asymmetric Provider，分别提供哈希加密和对称加密的功能。这里已对称加密的设置为例来说明，在Symmetric Provider节点上点右键，New->Symmetric Algorithm Provider，选RijndaelManaged，Rijndael是美国AES选定的加密标准，DES(原来的加密标准)会逐渐被放弃，.Net Framework中内置的Rijndael算法的secure key为32byte，IV为16byte，比其他算法强度都高，而且非常高效，是首先得对称加密算法。选定RijndaelManaged后，我们再选Generate创建一个对称密钥，然后确认就可以了。

⑵写代码

我们一般用其Façade类Cryptographer来写代码，

// 哈希算法的四个方法原型如下：

public static byte[] CreateHash(string hashInstance, byte[] plaintext);
public static string CreateHash(string hashInstance, string plaintext);
 
public static bool CompareHash(string hashInstance, byte[] plaintext, byte[] hashedText);
public static bool CompareHash(string hashInstance, string plaintext, string hashedText);
// 对称加解密的四个方法原型如下：
public static string EncryptSymmetric(string symmetricInstance, string plaintext);
public static byte[] EncryptSymmetric(string symmetricInstance, byte[] plaintext);
 
public static string DecryptSymmetric(string symmetricInstance, string ciphertextBase64);
public static byte[] DecryptSymmetric(string symmetricInstance, byte[] ciphertext);
 
①对称加密代码
//加密
private const string symmProvider = "SymmProvider";
string cipherText = Cryptographer.EncryptSymmetric(symmProvider, 要加密的文本);
//解密
string plainText = Cryptographer.DecryptSymmetric(symmProvider, 密码文本);
// 或者用下面的代码

//加密
String[] cipherText = Cryptographer.EncryptSymmetric(symmProvider, Encoding.Unicode.GetBytes(password));
//解密
string[] plainText = Cryptographer.DecryptSymmetric(symmProvider, Encoding.Unicode.GetBytes(password));

注意这里的symmProvider 是指标示具体的加密算法节点名称，如RijndaelManaged，而不是节点“Symmetric Providers”的名称。上面两种加解密代码，到底用那种要看你具体应用情况。

②哈希算法代码
private const string hashProvider = "PasswordHasher";
string hashPassword = Cryptographer.CreateHash(hashProvider, originalPassword);//生成摘要
bool isPass = Cryptographer.CompareHash(hashProvider, originalPassword, hashPassword);//比较是否与原来的相同
// 或者
String[] hashPassword = Cryptographer.CreateHash(hashProvider, Encoding.Unicode.GetBytes(password));//生成摘要
bool isPass = Cryptographer.CompareHash(hashProvider, Encoding.Unicode.GetBytes(password), hashPassword);//比较是否与原来的相同

还有就是用哈希加密时一定要用Salted hash，这样强度更高。

一、             日志应用程序块

1、概述

一般来说，日志模块是一个项目必不可少的部分。最常用的场景就是将对业务数据的操作记录下来，用于以后的安全审计。比如进行了何种操作，修改的数据是什么等等。其他的应用有：

------ 跟踪程序的运行，将运行中的一些信息记录下来，这对于程序开发时期和试用时期非常重要，我们可以根据这些信息对程序加以改进。

------将日志信息写到不同的地方，比如写系统日志中、写到数据库中，甚至发送email等。

------可定制的日志输出格式。

------将一条日志同时发往不同的地方。

------ 对于日志我们要设置其优先级，以决定是否记录，记录的位置、格式等等。

当然还有其他一些对日志的要求。在这里关键的是当我们对日志的处理策略发生该变时，我们往往要修改原代码，这不但要重新编译程序，而且会带来很大的工作量。日志应用程序块的出现改变了这种情况，我们可以在运行时改变配置文件，从而改变记录日志的种类、优先级、目的地等等。

在此我们以将日志写到数据库为例，简要介绍其用法

2、配置步骤

⑴添加日志应用程序块

添加后，我们可以看到日志和监控应用程序块有两个配置节，一个为Client Settings，一个为Distributor Settings。实际在物理上，系统用两个配置文件来分别保存着两个设置（loggingconfiguration.config和loggingdistributorconfiguration.config）。

Client Settings用于设置发布策略，这里有两种，即In Process和MSMQ。进程内发布是一种同步发布方式，我们比较常用，MSMQ是异步发布方式，用于将日志发布到MSMQ对列，由MSMQ依次处理。Distributor Settings用于设置各种类别的日志的发布目的地和格式，日志可以按不同的分类方式进行分类，这个我们自己掌握，比如可以将日志分为操作的安全审计日志、登录日志、跟踪日志等等，每种日志又具有持久化格式和发布目的地(也叫接收器)，在这里我们可以设置多种发布格式和接收器，在设置每种类别的发布格式和接收器时，可以从中选择。除了默认的接收器Event Log Sink和Flat File Sink外，我们这里还设置了一个Database Sink。

⑵添加日志Sink

也就是添加接收器类型，我们添加一个Database Sink，设置好其数据库实例名称和存储日志的SP名。

⑶添加日志类别

根据我们自己应用程序的要求添加类别，如安全审计日志、登录日志、跟踪日志等等，对于每个类别取一个比较有意义的名字。

⑷添加发布目的地

对于添加的每个日志类别，添加发布目的地，一个日志类别可以添加多个发布目的地，设置每个发布目的地的日志格式和接收器。

⑸设置完毕，保存退出。

3、写代码

记录日志的代码如下：

Logger.Write("logMessage", "LogCatagory", 1);

//或者

LogEntry logEntry = new LogEntry();

     logEntry.Category = " LogCatagory ";

     logEntry.Priority = 1;

     logEntry.Severity = Severity.Error;

     logEntry.Message = logMessage;

     Logger.Write(logEntry);

1、简介
数据应用程序块把我们从大量的机械的数据库访问代码中解放出来，同时给我们带来了在多个数据库甚至多个不同类型的数据库的中无缝切换的可能。
数据应用程序块的类继承层次非常简单，这里就不做详细介绍了(向看此文的朋友问个问题：为什么Vs.net2003的类视图窗口中很多类都不显示？)。
我们在我前面的配置应用程序块中提到过，要读取我们的自定义配置数据，首先要写一个配置数据类，数据应用程序块也不例外，这个类就是DatabaseSettings，其结构如下图：

从这个图里，我们可以看到DatabaseSettings主要包括3个集合类，DatabaseTypeData说明了配置的数据库类型，ConnectionStringData指明了每种数据库类型的连接串，InstanceData指明了当前的数据库实例。
2、使用说明
使用时分两步：先用配置控制台添加数据应用程序块，再在程序中写代码。
⑴用配置控制台添加数据应用程序块
①添加数据应用程序块，之后是分别设置应用程序要访问的数据库类型、每个类型的数据库即连接串和当前的默认数据库。
②添加应用程序要访问的数据库类型(Database Types)，如SQL Server、Oracle、Sybase、Access等
③设置每个数据库的连接串。添加上相应的连接参数。
④设定默认的数据库及其连接串。
⑤设置完毕，保存。
⑵写数据访问代码
数据应用程序块支持我们常见的大部分功能：执行SQL文本，执行存储过程、启用事务、离线处理、批量更新等等，下面我们分别举例说明。
①执行SQL语句
Database db = DatabaseFactory.CreateDatabase();
string sql = "SELECT * FROM [AddressList]";
DBCommandWrapper cmdWrapper = db.GetSqlStringCommandWrapper(sql);
return db.ExecuteDataSet(cmdWrapper);
②执行存储过程
Database db = DatabaseFactory.CreateDatabase();

string sqlCommand = "GetUserById";
DBCommandWrapper cmd = db.GetStoredProcCommandWrapper(sqlCommand);
cmd.AddInParameter("@UserId", DbType.Int32, 1);
Literal1.Text = (string)db.ExecuteScalar(cmd);
③启用事务
Database db = DatabaseFactory.CreateDatabase();
string sqlCommand = "CreditAccount";
DBCommandWrapper creditCommandWrapper = db.GetStoredProcCommandWrapper(sqlCommand);
sqlCommand = "DebitAccount";
DBCommandWrapper debitCommandWrapper = db.GetStoredProcCommandWrapper(sqlCommand);
using (IDbConnection connection = db.GetConnection())//
{
 connection.Open();
 IDbTransaction transaction = connection.BeginTransaction();
 try
 {
  db.ExecuteNonQuery(creditCommandWrapper, transaction);
  db.ExecuteNonQuery(debitCommandWrapper, transaction);
  transaction.Commit();
  result = true;
 }
 catch
 {
  transaction.Rollback();
 }
 connection.Close();
 return result;
}
④批量更新
Database db = DatabaseFactory.CreateDatabase();
DataSet productsDataSet = new DataSet();
string sqlCommand = "Select ProductID, ProductName, CategoryID, UnitPrice, LastUpdate From Products";
DBCommandWrapper dbCommandWrapper = db.GetSqlStringCommandWrapper(sqlCommand);
string productsTable = "Products";

db.LoadDataSet(dbCommandWrapper, productsDataSet, productsTable);

DataTable table = productsDataSet.Tables[productsTable];
DataRow addedRow = table.Rows.Add(new object[] {DBNull.Value, "New product", 11, 25});
table.Rows[0]["ProductName"] = "Modified product";

DBCommandWrapper insertCommandWrapper = db.GetStoredProcCommandWrapper("AddProduct");
insertCommandWrapper.AddInParameter("@ProductName", DbType.String, "ProductName", DataRowVersion.Current);
insertCommandWrapper.AddInParameter("@CategoryID", DbType.Int32, "CategoryID", DataRowVersion.Current);
insertCommandWrapper.AddInParameter("@UnitPrice", DbType.Currency, "UnitPrice", DataRowVersion.Current);

DBCommandWrapper deleteCommandWrapper = db.GetStoredProcCommandWrapper("DeleteProduct");
deleteCommandWrapper.AddInParameter("@ProductID", DbType.Int32, "ProductID", DataRowVersion.Current);

DBCommandWrapper updateCommandWrapper = db.GetStoredProcCommandWrapper("UpdateProduct");
updateCommandWrapper.AddInParameter("@ProductID", DbType.Int32, "ProductID", DataRowVersion.Current);
updateCommandWrapper.AddInParameter("@ProductName", DbType.String, "ProductName", DataRowVersion.Current);
updateCommandWrapper.AddInParameter("@LastUpdate", DbType.DateTime, "LastUpdate", DataRowVersion.Current);

int rowsAffected = db.UpdateDataSet(productsDataSet, "Products", insertCommandWrapper, updateCommandWrapper,
deleteCommandWrapper, UpdateBehavior.Standard);
这里的代码来源于Quick Start,这里需要注意的就是DataRowVersion.Current，批量更新时根据具体情况选择其值。同时ExecuteScalar、UpdateDataSet等方法重载好几个不同的方法原型，您可以根据具体情况选择。
⑶注意的问题
这里需要注意的就是在执行存储过程时，有两个获取IDbCommand对象的方法：
public abstract DBCommandWrapper GetStoredProcCommandWrapper(string storedProcedureName);
public abstract DBCommandWrapper GetStoredProcCommandWrapper(string storedProcedureName, params object[] parameterValues);
如果你要缓存参数，就用第二个方法，不缓存参数就用第一个方法(不知我说的对不对？)，因为在准备IDbCommand对象时，有下面的语句，
if (command.IsFurtherPreparationNeeded())
{
      parameterCache.FillParameters(command, ParameterToken);
}
这样，在用第二个方法时，会从缓存中取参数，当你多次调用同一存储过程时，可以考虑用用第二个方法，当然，如果有必要可以缓存执行的结果，性能更佳，这将用到缓存应用程序块。

还需要提一句，就是对于保存在配置文件中的数据库信息，我们也是可以加密的，方法与配置应用程序块的加密方式一致。可以看我关于配置应用程序块的使用方法说明。每个应用程序块的配置数据都是可以加密保存的。

有人已经制作了使用数据应用程序块的模板，比较不错：http://cstemplates.sourceforge.net