反思一下，我为什么需要这些技术？

在经历了多个项目的开发后，某天开始，我发现自己很少回顾自已的做法是否正确，只一味追赶概念和进度。于是认真列了一个以下几项

1、.net 2.0

2、nhibernate

3、NVeloctiy

4、SQL Server2000

5、MemCached

6、FIFO

以上这些是我做项目的4件主要技术内容

1、选择.net2.0 是因为nhibernate现在还不能运行于.net 2.0以上的版本中，而我又特别需要一个ORM框架来帮我解决基本数据存取的问题。

2、选择nhibernate是因为我测试过linq to sql，发现nhiberate比它效率要高很多，但性能都与ado.net吃平。

3、选择NVelocity，因为.net下的除了它自带的页面代码绑定就没有别的模板引擎可以用了，我需要一个模板引擎来解决项目内的分工问题

4、选择sql server2000是因为体积少，对硬件要求低，其实也是说明了我们硬件条件差。

5、选择MemCached，在分布式缓存的队伍里，我很高兴能找到一个可以在Windows下正常工作，性能较高，稳定性强的。

好回过头来

1、为什么需要一个ORM引擎？它真的好过dbhelper吗？

　　a)、ORM有现成的生成工具codesmith，用dbhelper时也可以同时使用面向对象的方法来解决问题。ORM 9分 DBHelper7分

     b)、使用ORM引擎可以方便的进行数据库基本操作，无需复杂的代码。dbhelper要自己写sql语句，但orm普遍性能较低，在大规模数据应用时不占优势。orm 7分 dbhelper 8分

     c)、使用orm可以方便地对底层数据库进行切换，使项目在迁移时不需要太多修订代码。dbhelper如果使用接口模式来写的话也可以使用多个数据库的provider实现，基本都能找着现成的。话也说回来，基本不会有太多个项目需要在底层数据库做迁移，用户关心是的功能的实现及功能实现的效果，基本不关心底层用什么数据库，如果一种数据库用的很好也不会主动要求更换数据库。所以也没什么大的必要。orm 9分 dbhelper 9分。

     d)、orm系统技术先进，带各级缓存，但针对小项目组来讲如果人员不十分稳定的情况下，orm带来的技术门槛其实就是一种很现实的风险，而dbhelper方式相对来说性能可以接近数据库能发挥出来的极限了，缺点是没缓存，但优点是不会有脏数据。在实现上以SQL技术为主，开发门槛低。说白了会的人多，谁都能做。项目的风险性小。orm 7分 dbhelper 8分

2、为什么需要一个nvelocity吗？asp.net自身的框架就是代码绑定的模板模式

 在独立开发的时候可能几天就可以完成一个功能的实现，从代码到页面。项目慢慢大起来，这种开发模式越来越显示出它的不足。

   a)、美工写好的页面拆成HTML后，向ASPX页面中套用，那又是对程序扒掉层皮的感觉，控件全部要重新拖过。ASP自带代码绑定0分。

   b)、自带的事件驱动方式会让开发的人习惯地以delphi的模式开发，OO全无。30分

   c)、但考虑到某些具体的小功能时，用自带控件可以迅速实现功能，在成本与代价权衡下很高兴可以“被迫”使用一下，也很享受。80分

3、MemCached

   这个东西太好了，我对作者先投以无比的崇敬。无论做多机系统，还是WEB与winform系统，还是其它异质的系统，都可以通过这个纽带把大家联系在一起。虽然为了保证稳定性使用的是TCP，每次取数据都会多那么几ms，比共享内存慢些，但在大规模数据读取应用时它的优势非常明显。

   memcached几乎影响了我对原有自己用着非常熟练的架框的改写，在数据持久层，尤其是数据读取频繁的我都引入了memcached。

   使用缓存带的的麻烦无外脏读脏写，这也不是memcached的问题。目前也没又考虑到性能又考虑到准确性的完美解决方案。

4、FIFO

   从高中开始就在玩计算机写小程序了，但由于不是专业搞这行的，很少研究数据结构，为此也浪费了很多情思去造轮子。

   FIFO也是我造过的轮子之一。特别是在处理高并发，实时性要求不高的处理时，自己设计了挺多方法，回头看来就是个FIFO。

   特别是线程安全自动阻塞的FIFO，在C#里实现也很简单，这种经典的数据结构对开发不异于屠龙刀。

   时刻要提醒自己，虽然不要迷失在新技术的森林里，但也不能再去发明轮子了，在经典技术的台阶前，还是要“无耻”的站上去。

随时补充。。。。。