自定义了页面周期
使用唯一的一个VelocityEngine全局的静态实例，优化了小泥鳅blog中每次请求都要创建VelocityEngine实例对象，减少了对象的开销
通过UA判断请求来自的设备，从而初始化不同的模板目录，从而实现手机和PC访问展示出不同的页面效果
一次请求的生命周期
参数初始化 Page_Init：
初始化请求上下文对象
请求对象
Cookie对象
货币对象
语言对象
初始化货币执行业务逻辑并写入到客户端的Cookie中
验证用户的身份 Authenticate_User
页面预加载 Page_PreLoad：会加载一些公共的数据，比如：图片URL地址，广告图片地址...；加载语言包数据；判断Form参数个数引发Post事件
页面加载事件 Page_Load：需要留给各个子页面实现，必须实现的一个，主要在子页面中完成各自的业务处理，数据获取与填充
页面预结束事件 Page_PreEnd：暂时还没有做处理
页面结束事件 Page_End：合并模板和业务数据
this.pcMobile【判断请求时做的初始化】 + this.templateFile 【在各个子页面重写Page_Load事件时做初始化】
用户验证逻辑的实现
使用虚拟的protected virtual void Authenticate_User()来实现，这样可以被子类重写，从而可以做后台管理类的程序，比如会员中心里面的页面，需要用户登录之后才能访问
判断用户登录使用的是检查session中登陆的用户对象来实现的 同时还有关于匿名用户登陆的问题，这个在后面解决
产品价格--多货币的实现
多货币 它属于每个访客自定义的数据，所以它不能存储在Application中，应该存储在Cookie中，或者session中
Octopus使用是Cookie的方式实现的
不让Entity承担过多的业务逻辑
在写的过程中，为货币Cookie的问题困扰了好久，产品价格的计算需要，产品对象拿到货币对象之后才能进行
起初我是在Entity中读取Cookie值来获得货币对象，后来发现这样做不好
一是，每个产品对象的创建需要不能的读取cookie
二是，在ProductInfo 实体中承担了过多的业务处理逻辑
再者，好像在entity中不应该有访问Cookie之类的代码吧，
后来进行了改进，将这部分代码转移到业务层，在业务层中接收CurrencyInfo对象，对ProductInfo对象做属性的初始化，这样解决了这个问题
同时cookie的读取则转移到了表现层的Page_Load中，而且并不是直接访问cookie，而是在数据上下文容器中取得货币符号，进而得到货币兑现来实现的
这个算是比较成功一次代码的升级