SQL注入攻击防御方案

除了让系统更慢，看不出有啥么用。属于补丁类，填上前面挖的坑？

建议楼主将代码放在google code上面 这样更方便学习

关于性能，文档中有描述：
WallFilter在运行之后，会使用LRU Cache算法维护一个白名单列表，白名单最多1000个SQL。正常的SQL在白名单中，每次检测只需要一次加锁和一次hash查找，预计在50 nano以内。在白名单之外的SQL检测，预计在50微秒以内。

基本上不影响应能。

代码托管，github比google code更靠谱吧！

我觉得没必要在什么情况下都考虑性能，我们不是阿里，简单好用就好了！

1000大概能够满足什么样的系统？

同意这点。

很多同学张口必谈性能，我的观点是：一个健壮的程序 和 一个性能很高，但是潜在问题很多的系统相比较，健壮的程序更重要。

理想的目标是：程序即健壮，又高性能，如果健壮性和性能一定要发生冲突，我选择健壮的程序。

以前做桌面软件开发，总是把性能放在第一位，对于用户可能的错误操作、错误键入内容等，全不做判断，也不进行任何过滤，自我安慰说这样是为了性能，用户不可能输入那些非法字符。

但是在软件的实际应用过程中，我发现，凡是你认为用户不可能进行的操作，客户都会给你翻来覆去地整几遍。

比如，以前做得一个通讯客户端软件，要求用户在软件上输入手机号，一行一个，设计软件的时候，为了性能，一直假设用户是完全遵从软件界面上的说明文字，一行一个手机号码，但是实际上，用户总是会给你弄一些“意外”，要么是一行两个手机号，要么数字中夹杂了其他符号，要么是这里那里有空格，要么是中间有两个连续空行……

软件经过用户实际一用，原来预想的“用户不可能进行的操作”，用户都会给你愣头愣脑地操作一遍，所以，最后我只能对每个用户输入域，都进行严格的输入时验证、提示，保存时过滤等一堆处理。

所以，性能再好，如果不够健壮，也只是一个脆弱的玻璃杯，一摔就碎。

如果软件健壮性一定要和性能有冲突，选择健壮是最正确的做法。

另外，无论是一个成品软件，还是一个辅助开发框架，都应该把易用性放在前面。
以我的自身经历来说：

以前做跨平台桌面软件的技术选型时，面对QT C++ 和 GTK C，我非常想用GTK，因为当时QT的授权还不够开放，怕以后软件有商业授权上的问题，所以我是很想用GTK的，但是经过仔细的对比，最终我还是选择了QT C++，因为，GTK相对于QT，GTK太麻烦了，文档一塌糊涂，开发工具凌乱无章，一个新手如果直接拿GTK来做开发，简直是自缚双手双脚，爬着向前走；

而QT，不但有完整、规范、详细的文档，而且有一堆现成的官方例子，几乎每个类库的用法，都有官方的权威例子，而且有官方提供的集成开发环境，新手学起来，非常舒服，一个有点C++经验的开发者，学两天就能用QT循序渐进地进行实际开发了。

所以，我觉得软件或者框架的易用性是非常重要的。

软件开发中的几个标准，我的个人排名是：

1、易用性
2、健壮性
3、性能

其他的，什么可扩展性、流行程度、生成的release软件体积的大小 等等，这些都排在上面三个指标的之下。
================================================================================
如果是大型企业，能够招聘到大量牛X技术人员，开发周期也放得很宽，员工有充足的时间对代码进行细琢磨，这样的话，就可以把“易用性”这一项给取消了，因为“易用性”的主要目的是：让开发者快速掌握用法、轻松学会使用技巧，避免错误操作。

如果是大型企业，“易用性”所带来的好处，完全可以用一堆牛X的开发人员 和 大量的钻研时间来填补，也就是虽然不好用，但是因为我有大量牛x开发人员，所以他们也能熟练掌握用法，也能避免误操作，这些压力，从软件/软件框架的身上，转移到了牛x开发人员的身上。

所以，对于不缺人才的大型企业，软件开发中的几个标准，排名应该是：
1、健壮性；
2、性能
===============================================================================
而对于中小企业，最大的成本，就是人力成本，而一个开发框架的易用与否，直接决定了员工要花多少时间去掌握它、去熟悉它，这样，如果是一个易用性差的开发框架，对于中小企业而言，直接导致的结果就是：开发周期延长再延长，软件出错的几率大大增加，企业的支出无谓地增加。

所以，对于中小型企业，“易用性”应该是放在第一位的，因为这直接和钱挂钩。

你是抱着老婆来看技术论坛？ 哈哈哈～

估计还没老婆吧