Aug 1
Apache Wicket 开发团队宣布Apache Wicket 1.4正式发布。Wicket是一个面向组件的开源Java框架。Wicket完全由Apache Wicket社区用户维护支持,本次发布的Wicket版本将不再兼容Java 1.4,而是最低需要Java 5的支持。您可以利用Java 5的泛型功能编写类型安全的应用程序,创建类型安全、自动生成文档,可以重用自定义组件的功能。

您可以通过修改maven pom.xml配置信息升级到最新的Wicket 1.4版本,修改代码如下:
<dependency>  
  <groupid>org.apache.wicket</groupid>  
  <artifactid>wicket</artifactid>  
  <version>1.4.0</version>  
</dependency>
Tags: , , ,
Jul 12
      深入开源世界的程序员的思维大多发散严重,这种发散在很多情况下是有害的。在制作一个新的产品/项目之前,很多人都会说,唔,你应该参考好的开源东西,把他直接使用。殊不知这样拿来就用伤害最大:因为自己根本没有机会仔细思考自己要做的东西是什么样子的。这就是Hibernate之所以创建EHCache的原因。在EHCache之前,已经有不少Cache实现,为什么没有直接使用?因为Hibernate自己都不知道Cache接口应该是什么样的。因此有了小小的简陋的EHCache, 正是有了这个小小的东西,其他Cache机制的集成才成为可能。因为Hibernate知道与外界集成要遵循的接口是什么。如果当初直接采用某一种Cache实现,恐怕就没有了现在灵活的Cache机制了。(这种思维的方式同样可以推广,为什么小公司不愿意接受数额较大的融资,因为这样很容易将小公司原本不太清晰的发展观念冲垮,最后什么也不是。)

      现在设计平台,发现陷入了这样一个怪圈:我总想将最新最好的开源产品集成到平台中,却忽略了Roadmap Feature的定义,也就是说,没有一个清晰的标尺来定义平台某一个版本应该包含那些特征,应该达到什么效果。这样做的后果是我陷入在一个又一个优秀的产品中,像上瘾的烟鬼拔不出来。在深邃的开源世界里,一切的一切都太又诱惑了:为了选定一种O/R映射方案,我比较了JDO的各种实现以及Hibernate,阅读了大量文档(广告?),最后还是回归到Hibernate; 为了选定一种Mock测试方案,我比较了EasyMock, jMock, 之前我从未用过Mock测试,现在我对EasyMock的机制已经相当清楚了;为了选定一种代码覆盖率工具,我比较了Clover, Jcoverage和Emma,最后选定了Jcoverage, 为了选择一种IoC容器,我比较了Spring和 HiveMind,最后选定Spring, 为了选定一种Web开发框架,我重新审视并比较了SpringMVC, WebWork, Struts, Tapestry.,最后选定了Tapestry。这个过程充满了感叹,也充满了诱惑性:很多具有相关性设计精美的项目会时不时招摇的在你眼前晃来晃去,让你忍不住看下去,然后你一个下午的光阴就耗费在从Google或者TSS或者JavaLobby一个链接开始而引入的一个深渊,留下你无法弥补的4个小时的时间。看着越来越近的Release Date, 心情越来越不爽。
Tags: ,
Jul 7
星矢:动画片《圣斗士星矢》的男猪脚,超级小强,怎么打也打不死。
雅典娜:动画片《圣斗士星矢》的女猪脚,自称女神,手下有88个男人为他卖命。
状态模式:为了方便的控制状态的变化,避免一堆IF/ELSE,以及状态规则改变的时避免代码改动的混乱。
观察者模式:一个被观察者一动,多个观察者跟着动,经常用于界面UI。

话说星矢和很强的某斗士甲对打,雅典娜在一边看,星矢总是挨揍,每次挨揍完之后星矢的状态总是会发生一些变化:

正常--挨打--瀕死--挨打--小宇宙爆发--挨打--瀕死--挨打--女神护体--挨打(星矢无敌了,打也没用,战斗结束)--正常

以上状态转变用状态模式来表现,一个Saiya类代表星矢,一个SaiyaState代表他的状态,SaiyaState下面有多个子类,分别代表星矢的多种状态,如正常NORMAL、瀕死DYING、小宇宙爆发UNIVERSE、女神护体GODDESS,即把状态抽象成对象,在每种状态里面实现被打的时候所需要更改的状态,这样就避免了每次被打都要进行一次IF/ELSE的判断。
Jun 25
软件架构设计其实分为三方面的问题:

1、软件逻辑架构设计,逻辑架构设计主要设计软件的模块组成,模块分层,模块间的接口和契约,只有细化模块设计的时候,才可能考虑到所谓三层结构问题,可能很多的人都把模块的细化设计看成了架构设计
2、系统架构设计,系统架构设计要考虑的问题就是系统的伸缩性,可扩展性,安全性,稳定性、高性能性等方面的问题,这个时候主要考虑WEB服务器、数据库服务器怎么部署,考虑热备问题,大缓存问题,集群问题、加密访问(如VPN)等方面的问题。这里面会涉及到大量的性能估算问题,这才是考验功力的地方。
3、物理架构设计,物理架构设计主要考虑硬件的物理放置问题,要考虑到流量的分配、代理问题等,这方面我不是很了解。

对软件架构的设计居然在相当长的一段时间里面存在误区,居然把软件架构设计和程序框架结构设计混淆等同,以为就架构设计就是设计那些三层结构怎么划分,怎么流转的问题!
Jun 24
话说有一个银行,有三个窗口,但是每个窗口的智能都是一样的,即都能办理所有的业务。因此每位来银行办理业务的人只要排队就是了,排到你了,就向业务员说明你要办理的业务,然后业务员根据你的业务选择不同的单据,打开不同的账本。……。

业务员此时典型的工作流程是:
if (service instanceof Saving){  
    //存款  
   ......  
}else if (service instanceof Draw){  
    //提款  
   ......  
}else if (service instanceof Fund){  
    //基金  
   ......  
}    
......
Jun 20
      业务场景,Department和Employee是一对多关系。现在我对Department进行分页查询,要求在显示的页面上同时显示每个Department中Employee的数量。这是一个很简单的业务场景,但是想象一下如何用hibernate进行映射?

      首先否定一种做法:hql:FROM Department department。然后针对每个department,去做department.getEmployees().size()。这样不仅会发送n+1条SQL,而且性能太低。

      我们肯定希望采用一句HQL解决问题,但是此时问题来了,当你试图做SELECT department, count(employee.id) FROM .....这样的HQL时,在Java端,发现没有一个合适的对象可以映射。
Tags: ,
分页: 3/9 第一页 上页 1 2 3 4 5 6 7 8 9 下页 最后页 [ 显示模式: 摘要 | 列表 ]