读《应用rails进行敏捷web开发》第2版-15

今天上午整理了一下系统：

  原先一次性支付的费用要改成3次支付，于是改计费系统、查询系统、业务系统，增删了几个存储过程和数据库函数，全面做好了升级的准备。就等确定实施日期了。

  高扩展性的系统，会造成性能下降——由于增加了原先不需要的一些计费，目前一条记录存入，需要进行50+次查询，好计算其费用，这个有待优化，提高响应速度。

 

  下午，业务系统和查询系统外网崩溃了。

  跑到机房，由于服务器上没有标签，kvm到一台服务器（windows 2003）上，发现密码不管用，以为被黑了，赶紧修复，把admin的密码给破解了，冲进去一看，咦？怎么是SQLServer！！而且没有WebsPhere喃？最终确定这不是公司的服务器！！！！！汗。。。

  赶紧把网管叫来，让他自己把密码重新设置了。才又找到自己的服务器，发现已经运行了133天了，133天的websphere是很不正常的。 重启后发现还是没好，又跟网管沟通了一下，结果是网管同学把必要的两口端口的外网访问给关了，泪奔了。。还好，下班前搞定了。

 

---

开始p445

flash

#确定花 flash[:notice] = "some message" #击鼓传花 flash.now[:notice] #继续击鼓传花 flash.keep(:notice) #继续击鼓传所有的花 flash.keep

文中说flash.now用于将变量从控制器传到视图，有这个必要嘛？视图可以直接访问控制器变量的呀？

 

过滤器

3种过滤器before、after、around都可以访问控制器的request和response变量

 

过滤器可以使用3种方式定义

#1.方法 before_filter :a_filter #2.块(参数：controller） before_filter do |controller| xxx end #3.类(参数：controller） class c_filter def self.filter(controller) xxx end end before_filter c_filter

 

around过滤器

#方法方式的实现 around_filter :d_filter def d_filter xxx #yield 就是action执行部分 yield render(action_name) end #代码块方式的实现 around_filter do |ctrl,act| xxx #注意call的用法 act.call render (ctrl.action_name) end #类方式的实现 class my_filter def filter(ctrl) xxx yield render(ctrl.action_name) end end around_filter my.filter.new #注意和上面类方式实现的区别，这次的filter是实例方法，因#此定义around_filter后面的是实例；而前者定义的类方法，因#此around_filter后面跟的是类名

 

 

过滤器可以依照继承的关系继续，但不向上兼容，即子类过滤器对父类无效。这也是应该的，子类的定义本来就不应该影响父类。

#不执行父类的某过滤器 skip_before_filter :a_filter skip_after_filter :b_filter #忽略所有过滤器，仅对方法方式定义的过滤器有效 skip_filter

 

 

校验（注意，此处的校验是控制器的校验，不同于模型层的校验，因此在代码上，要分清楚一个校验应该在控制器进行还是模型进行）

 

verify #选项1：控制范围 :only=>:post_comment, #选项2：条件 #session中包含 :session=>:user_id, #xhr 是否是ajax条用 :xhr=>true, #flash中包含 :flash=>:notice, #请求方法 :method=>[:get,:post], #params中包含 :params=>[:id,:name,:email], #选项3：动作 :add_flash=>{:error=>"xxx",:notice=>"xxx} :redirect_to =>{} :render=>{}

 

 

缓存

要缓存，必须保证同一个url出现的页面是不变的，才有必要使用。

3种缓存方式：页面缓存、action缓存、片段缓存

页面缓存：rails不参与，web服务器直接搞定

action缓存：执行前置过滤器，不执行action代码

def method1 xxx end def method2 xxx end #页面缓存method1方法的响应 caches_page :method1 #action缓存method1方法的响应 caches_action :method2

action 缓存机制其实就是around_filter

 

 

是否使用缓存的原则：我们的应用得知道缓存是否失效了。

1.依赖时间变化的页面

2.依赖session变换的

3.依赖数据库数据，同时数据库数据除了应用本身会被外部更改的

都不适合使用缓存

expire_page expire_action

使用和url_for一样的参数，生成的url相应的缓存会被删除。

 

什么时候删除？

如果缓存首页的数据列表，那么在新增文章（create_article)里就应该expire缓存。

 

清扫器sweeper是一个observe，上面的方法耦合性过强

sweeper检测model，通过model的钩子方法（after_create之类）监视model变化，根据变化调用expire_page、expire_action来使控制器缓存失效，代码不贴了，太长，懒得敲。

#控制器代码 class AricleController<AppliactionController #激活sweeper cache_sweeper :article_sweeper #ArticleSweeper类 :only=>[:create_article, :update_article, :destroy_article] end

 

理一下头绪。

1.controller通过cache_sweeper，开启清扫监视

2.当被监视的action被调用（随后model可能发生变化），sweeper开始工作，

3.sweeper根据model变化，决定缓存是否失效。