摘要:抛开技术细节不说，我今天很想记一种精神、一种态度，请来看看博客堂的“弟弟”博客园上面的一个话题： 关于.Text如何过滤恶意脚本的思考小题大作:.Text中恶意脚本过滤的新方法 应该是受我文章的“误导”，dudu同学坚定不移的要用些（我已暗示多次并不合适的）新技术、新思路去解决一个很多中手、高手都不屑于解决的问题。他自己钻研文章，多次通过邮件向我提出自己的质疑，与我讨论相关的技术，最后终于成功的从完全不同的角度解决了问题，还发信来让我批评他写的程序……很多朋友问我如何可以成长为高手，这下我可找到教材了。：） 星星之火，可以燎原。一个社区的力量终归还是出自每个人的身上。所以我想，对外的广告是要这么打：Inspired community, inspiring people! 但对内的口号应该这样说：Inspired people, inspiring community!...[阅读全文]

摘要:继续前面的话题，上次给出了个不甚明确的大图画，结果引来众多高手指教，不亦乐乎！这次我想明确一下、具体化一下，就是下面这样一个命题（C#示意性代码）： 如果有：  [TableMapping("Book")]public class BookInfo{  public BookInfo(int bookID, string title, string publisher);  public int BookID;  public string Title;  public string Publisher;}   怎样将这段代码：  public BookInfo[] SelectByPublisher(string Publisher){  SqlCommand command = new SqlCommand();  command.CommandType = CommandType.Text;  command.CommandText = "SELECT BookID, Title, Publisher FROM Book WHERE Publisher=@Publisher";  command.Parameters.Add("@Publisher", Publisher);  using (SqlConnection connection = new SqlConnection(connectionString))  {    command.Connection = connection;    connection.Open();    SqlDataReader reader = command.ExecuteReader();    if (!reader.HasRows) return new BookInfo[0];    ArrayList result = new ArrayList();    while (reader.Read())    {      result.Add(new BookInfo(reader[0], reader[1], reader[2]));          }    return (BookInfo[])result.ToArray(typeof(BookInfo));  }}   用这样的统一方式来轻巧的实现：  public BookInfo[] SelectByPublisher(string Publisher){  return (BookInfo[])ElegantORM.Execute(Publisher);}   显然，我们需要实现ElegantORM（暂且不论这个codename起的多烂啦：）这个helper。怎么实现最合理？它应该能够支持前文所述的几种常见数据访问组件接口方法的signature，且不仅依赖于使用custom attributes的映射元数据（即可扩展到支持外部映射配置文件等等）……   BTW: 在本文下我们不讨论三层结构相关的话题（不过欢迎你把这方面的见解继续发到我的前一个随笔中：），只针对这个具体命题的设计和实现，我很想听到大家的见解并分享自己的心得。：）...[阅读全文]

摘要:前面用透明代理机制实现简单AOP的文章一发，很快收到很多朋友的反馈，其中就有一些朋友提出关于文中所述的透明代理等技术还能够用于什么应用场合的疑问。说实在的，本来我就是想写一些关于这些技术在实际项目中应用的随笔的，可是想到可能会有很多朋友对这些技术的基本原理还不熟悉，这才萌生了先写一系列文章作铺垫的念头（可惜由于工作比较忙的缘故，至今还欠一篇没有写完，还请大家见谅啦，我抓紧时间补上——这篇内容更精彩噢！呵呵）。   今天我们又一次把我前面这两篇文字中提到的技术应用在项目开发中，初步反馈还是非常positive的，这里我不妨把问题先说出来，请看过文章的朋友们好好想想，看看如何利用已经学到的知识来解决这个实际问题吧——稍后我会回来说说我的想法（当然如果大家看过偶的文章以后都能够想出这种解决方案的话那当然就最好了：），当然如果你有其他更好的办法，更是欢迎你通过发表评论和大家分享！   这个问题和单元测试（Unit Testing）有密切关系（虽然我们的项目还不能算是完全的TDD，但是充分、必要的单元测试还是不可或缺），这里我们还是以简单的例子来说明，比如这里有一个银行服务的接口：   interface IBankService{  void Withdraw(Account account, int amount);  void Deposit(Account account, int amount);  int QueryBalance(Account account);}   这个接口的三个方法的作用很简单：取款、存款、查询余额。我们肯定要开发一个实现这个接口的具体业务操作类；与此同时，由于该服务接口对安全性的严格要求，项目组中专门负责安全规则的部门将以DECORATOR的方式针对该接口的每一个方法编写负责安全保障的修饰类（最终在运行时由组件工厂动态组合）。以这种设计方式，只要确定了服务接口，则两个类的开发就可以充分的并行进行了——真的是这样吗？我们写写看：   class BankServiceSecurityGuard: ComponentDecorator, IBankService{  void IBankService.Withdraw(Account account, int amount)  {    if ( … )      throw new DailyAmountExceedsException( … );    if ( … )      throw new AccountBlockedException( … );    if ( … )      throw new PermissionNotGrantedException( … );    …    ((IBankService)Decoratee).Withdraw(account, amount);      }  …}   这个方法的实现就是一个把门儿的逻辑：结合方法调用参数使尽各种必要手段确保只有在符合所有安全规则的前提下才能够把调用转发到被修饰的（即decoratee）对象（也就是IBankService的核心实现类上）。也就是说，开发并测试这个安全保障修饰类的时候最终还是要依赖于一个能够工作的核心实现类，否则就算可以编译通过（还好这种依赖已经被接口隔离开了），你也无法让单元测试通过。我们能不能用什么办法来独立的测试这个修饰对象使之不依赖于一个正确工作的核心实现类呢？换句话说，有没有办法在没有可工作的核心实现类的情况下（这种情况常见于核心类开发周期较长的时候），让下面针对安全保障修饰类的单元测试代码正常起到单元测试的作用（一是驱动开发过程、二是形成软件规格说明、三是跟踪软件缺陷……）呢（我们先假设Account类是已经存在且经过充分测试的——其实对该类的隔离测试也是类似的道理）？   [TestFixture]public class BankServiceSecurityTest{  private IBankService bankService;  [SetUp]  public void Initialization()  {    bankService = new BankServiceSecurityGuard(???);  }  [ExpectedException(typeof(DailyAmountExceedsException))]  public void TestForExceedingDailyAmount()  {    AccountState state = AccountState.DailyAmountReached;    Account account = new MockAccount(state);    bankService.Withdraw(10);  }  public void TestForNormalWithdraw()  {    AccountState state = AccountState.Normal;    int initialBalance =......[阅读全文]