2007-12-30
全文显示

谈谈应用ORM框架针对遗留数据库做模型设计的一些技巧。

很多项目的开发都是基于已有数据库做开发的。遗留数据库的存在增加了java模型和数据模型之间的障碍。 很多朋友为此是否选择hibernate或者别的Jdbc wrapper的开发框架而犹豫不决。 其实，用hibernate类似的orm工具总归是明智的选择，当然不是唯一的明智的选择，我写这篇文章只是希望能够给那些还在犹豫不决的人提供一些自信的力量，可以果断的作出自己的决定。 有一个朋友询问过针对遗留系统做模型设计的问题 。很难简单回答这个问题，但是我可以提供我的一些经验，同时也把这篇帖子作为对那位朋友的一个完整的回答，希望能顾对他有所帮助。 针对统一的业务逻辑，对 业务模型，DAO/S ...
2007-12-14
全文显示

一个简易的ruby AOP框架 。

在开发smart memcache的过程中 ，开发了一个简易的 ruby aop 。 支持 before,after,rescue 的拦截，支持重复，任意组合的拦截声明 。 在后续的版本支持 arround interceptor声明。 基本的使用代码如下: after 拦截使用: @ruby_aop = AOP::RubyAop.new @ruby_aop.interceptor(:classes=>["User","Teacher"],:methods=>[:update_all],:interceptor_type=>:after) { |aop_info,*args| ...
2007-12-10
全文显示

关于实现一个rails smart cache 的思路草稿。

最近研究了一下 rails的cache设计，发现其中一些不尽如人意的地方: * cache expiry 编写繁琐 * 分页缓存的清除，现有cache实现的支持都不是很完善 * 在一次清除大量缓存的时候，脏数据读的问题。 我查阅了一些blog以及相关的文章，从他们的抱怨和设计中得到一些启发，我觉得cache可以做得更好，更智能，更能够减少开发人员的工作量。 下面是我设计思路的一些草稿，如果深入分析，觉得可行的话，就可以动手做他: * 支持 cache 分组。 * 支持简化的expiry rules * 适当的设计减少一次清除大量缓存时脏数据读的概率和时间窗 * 仅考虑me ...
2007-12-08
全文显示

PATCH for restore fixtures data after every test running

rails的fixtures有一个令人讨厌的地方： fixtures 的数据不会在测试结束后自动清除 ，这样就使得fixtures遗留的数据影响到后来的测试。 相关的争论也持续了很久 ，具体的连接请看 http://dev.rubyonrails.org/ticket/2404 里面的 Rick的patch我在rspec下用了，不见好用，我只能自己搞了一个patch，在rspec的 spec_helper.rb下引入 ，解决了这个问题 。 patch主要的思路是： 每次测试setup运行前插入fixture的数据，保证这个插入 fixtures数据的事务和test运行时的事务是同一 ...
firebody
搜索本博客
最近加入圈子
存档
最新评论