先说一下openfans最早版本的整体设计。首先是用Equinox直接new出项目来，它默认是springmvc+spring+hibernate再加上一些常用的组件，如sitemesh，common-validator，dwr等。而这些都是我们想要的。
有了这个大的框架，我们可以进行业务建模了，我们采用的是领域模型驱动的设计方案。首先考虑的是对象以及对象间的关联，我们也没用什么建模工具和自动生成工具，先自己写java类，写好属性，用eclipse生成get和set。然后手写hibernate的hbm配置文件，有点土，这也是我第一正式的使用hibernate。开始我用了dao模式，写了好多dao，后来和oofrank讨论，一直认为hibernate就是我们的持久层，完全没有必要为了移植性（如将来使用ibatis）而引入dao。所以抛弃了dao模式，而由一个façade处理持久。这样的设计跟一般的三层模型略有不同，hibernate就是我们的持久层，然后通过一个façade提供对上层的接口。领域模型和mvc中的c充当我们的业务层。我们的对象不是贫血模型，而是有能力的。当然现在这种能力更多是对象间的关联，而对持久层无能为力，但也已经方便了很多。Controller现在具有较多的功能，它能调领域对象，也能直接使用façade。然后是jsp+jstl+el做纯粹的展现层。C和V的分类原则是这样的：一类是查看，一类是form提交。所有查看由一个viewController统一处理（这样增加了一些耦合，但效果还可以），一个对象的增、删、改由一个formController处理。
有了这些设计原则，做起来倒是很快，几天就核心功能出来了。对于数据库，只要建一个库就行，其余的如建表，改表等都由hibernate来自动帮你完成，数据库就是在写hbm时关心下，其它完全对我们透明，感觉还是挺爽的。 最初版一共就20几个类，完成了很多的功能，可以具体看
www.openfans.org 下一篇写怎么使用maven和tomcat，让openfans在自己机器上跑起来。先去吃饭了，^_^。大家有任何疑问和好的改进意见，都可以提，跟帖。
本网站旨在推动opensource软件在中国的传播和使用。应用web2.0的思想，提倡大家都来参与和有收获有贡献的风气。注册后就可以直接登录（将来需发email进行验证），登录近来就可以进行所有的操作了。
操作很简单，先可以点击上面的修改用户链接，补充自己的信息（现在只要填入blog地址、简单描述和所在地），这样能够让其它用户更好的了解你，还可以加一个你喜欢的图像上传（现在大小限制在10k以内）。
点击推荐软件链接，可以推荐你喜欢的开源软件。填入名称，主页，加上你的介绍或官方的介绍，然后给它个图标，就可以了。图标可以在它的主页上找到，然后将其url拷贝下来，就可以了。
在浏览软件时，你可以随时增加认为与其相关的标签（我们把软件认为是一种特殊的标签）。标签标题是不带空格的，我们可以填入用空格分割的多个标签，系统会依次增加这些标签关联。如hibernate，你认为它是持久层，也可以认为是O/Rmapping，已经关联的标签也可以再加，我们会增加其关联度。一个标签下的相关标签会按关联度从高到低排列。
更重要的是你说明自己对这个软件的使用情况，如熟练掌握、正在使用还是准备使用。简单的点击，会给软件和你增加有用的信息。我们会看到一个软件有多少人熟练掌握，有多少人正在使用，在进行同类软件横向比较时非常有用。而如果你在准备使用一个软件时，就可以看看有谁熟练掌握了这个软件，可以看他（她）的blog，或直接跟他（她）联系，更快的掌握这个软件。
如果你有好的心得体会或看到网上有好得相关文章，也可以在浏览标签的页面，点击发表文章链接，跟大家进行分享。别人也许就因为你的一篇文章快速入门了呢，呵呵！
将来还会有更多更好更酷的功能出来，我们永远会从用户角度出发，力求做到最好的用户体验。欢迎进入openfans的世界！
注册网站
www.openfans.org以及
www.openfans.net(现在www.openfans.net开通了
)，提供对开源软件的介绍和评论。应用web
2.0思想，体现社区自管理的原则，提倡对开源软件学习和交互。期望成为中国开源软件介绍和交流的主流平台之一，为开源软件在中国的传播和使用贡献自己的力量。
roadmap（暂定）：
0.1（4月底完成）--注册，登陆，权限管理，标签功能，发表软件介绍和文章
0.5（5月底完成）--评分体系，同城，小组和朋友管理
0.8（7月底完成）--sns功能，投票功能
1.0（9月底完成）--开始形成专家小组，提供项目外包和咨询管理平台
更多--随着平台的使用和更多的成员加入，不断加入新的功能
同时启动开源项目openfans，使用开源软件：eclipse,
maven2, spring(包括spring mvc), hibernate,
mysql,common-validator,sitemesh.....
目的是提供web2.0应用的基本模型，同步在www.openfans.net上进行验证和使用，并能够方便的移植到其它领域。
目前项目在sourceforge上，由pesome和oofrank共同管理。0.1版基本完成。
cvs -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openfans login
希望参与开发的同学请mailto:pes...@gmail.com，简单介绍自己并注明在sf上的用户名。
在google上开了一个站务论坛：http://groups.google.com/group/openfans
欢迎大家多来访问，推荐软件和文章，方便大家更快更好的找到自己最需要的东西！
项目组对log和exception的讨论结果。希望更多的人参与讨论。
1 log
1.1 用log.error表示系统级错误
1.2 用log.warn表示应用级错误
1.3 服务初始化或结束用log.info
1.4 用log.debug替代out，debug要判断isDebugEnable
1.5 用log.warn("",e)替代e.printstack
1.6 用log4e生成log相关代码
1.7 Log信息要保证可读性，需记录现场信息，如当前处理id等
2 exception
2.1 try catch内的代码不要太长
2.2 因为性能原因，try catch少放循环内
2.3 尽量避免catch(Exception)这样的写法
2.4 不同模块定义不同的exception
2.5 建议创建应用的基类exception，特别是有定义error code需要的应用
2.6 只要catch就要log error message
2.7 catch并封装成另一种exception，如果不nest原来的exception就要log stackTrace
2.8 持久层throw dataAccessException，业务层throw checked exception，展现层只显示exception信息
2.9 规范的exception流程定义如下：
业务层不需处理的runtime exception，由展现层定义的exception controller捕获，交给相应的error页面显示并记录stack信息。业务层捕获下层的exception，并封装成业务层的checked exception，如果nest所捕获的exception，则仅log error message，如果不nest就需要用log.warn(“”,e)记录stack信息。展现层捕获业务层的exception，应由处理业务层exception的error页面来处理。
对spring框架和开发模式进行了验证。大家有什么问题或好的建议，请回复，大家一起讨论！
一、 项目目标及完成情况
|
目标 |
完成情况 |
|
技术验证和推广 |
完成较好。
1． 共有7人实际参与项目开发，我们引入maven2作为构建工具，eclipse作为ide环境。大家都能在很短的时间初始化项目，并快速掌握各自需要的技术（如spring，spring mvc等）进行开发。
2． 对分层开发的模式也进行了探讨，证明它是可行的：可以各层并行开发，提高开发效率；而通过分层可以隔离关注点，使得各层开发人员可以只关注本层相关技术和接口，减轻开发人员负担，提高效率。
3． 在项目活动中碰到一些技术难点，我们将解决方案文档化，然后项目内共享，这样能在碰到同样问题时快速解决。现在还是碰到问题才解决，以后需要建立预研机制，较早发现可能出现的难点，尽早解决，避免对项目进展产生影响。
4． 平台还处于建设阶段，对项目的支持还不够，需要形成一些通用的组件。 |
|
过程和管理实施 |
有待提高。
1． 测试1.0版已发布，目前开发1。1版，完善分页功能和采用更好的验证方式。由于对规范开发的项目周期估计不足，加上管理上的一些问题，导致项目有所延期，需要对实际的项目开发进行量化分析，确立比较准确的人员和时间计划。
2． UC文档规范和编码规范等的引入，为项目提供了较好的支持。
3． 在实施中比较缺乏必要的文档支持，如设计文档等；同时各层的接口定义也出现较多问题，导致一些开发瓶颈的出现，这都需要在正式迭代中改进。 |
|
系统功能 |
完成较好。
1． 完成了UC文档确定的功能点，页面美观，使用方便，能给用户较好的页面体验。
2． 采用较好的面向对象设计，能提供一定的可重用性和扩展性。 |
二、展现层总结
经验与教训
1. SpringMVC是一个简洁、标准的MVC实现，结构清晰，功能强大（主要体现在对日常WEB开发中可能遇到的各种常见问题的解决方案），有一定学习曲线，但是有其它MVC框架基础的开发人员可以较快上手；
2. 根据业务功能尽早确定接口，接口由展现层确定，由业务层实现；
3. 合理选择Controller可以减少开发工作量，前提是充分理解每种Controller的处理机制及其回调方法细节，Controller的编写更多的精力主要花在校验、出错处理上；
4. 页面工作量很大，特别是需要比较复杂javascript的页面；
5. UI的流转设计等对于Controller的编写和业务层的接口有着很大的影响，应尽早明确，否则会产生较大的返工；
6. 展现层开发可以与业务层同步进行，推荐确定接口后，就编写业务层接口的mock实现，放在展现层的test包内，同时写单独的测试用spring配置文件；
待解决问题
1. Controller是否应写test case，本次开发未做；
2. 如何减少校验的工作量，对于有业务逻辑的服务端校验如何实现，是否需要采用一些validator框架，如sun的JEF的validator组件，目前我们进行了研究，通过使用commons validator组件能够较方便的实现validator；
三、业务层总结
经验与教训：
1. Spring，iBatis的应用还是很成功的，学习曲线比较平滑，好的框架好掌握；
2. 比较重视测试，编写很多测试案例，并频繁使用maven运行所有测试，使得问题能够及早发现，保证了各层能够快速成功集成
3. 对于很多问题都需要经过各层间的讨论来确定；
4. 接口由展现层定义，由业务层实现；
5. 持久层数据模型和领域模型是有区别的，但简单的情况下可以合二为一；
6. Façade模式还是很有价值的；
7. 一些开源软件的使用需要比较小心，如iBatis的null的问题等，如果处理不当会花费较多的人力物力，需要技术较强的人对开源软件花费一定时间进行源码级的研究，才能找出较好的解决方案；
8. 认识到设计的重要性，需要对前置、后置条件等进行分析；
9. 数据类型分析简单，造成数据库设计对业务层产生不良影响；
待解决问题：
1. 沟通不够，需要建立沟通渠道，是否可以有专门的场合和时间讨论项目中的进度和问题；
2. 计划不明确，对于要完成哪些功能，完成到什么程度，没有明确的定义，需要设置里程碑目标。在正式迭代开始前，要明确每次迭代的任务和目标，需要结合业务需求进行计划；
四、持久层总结
经验与教训：
1． 通过代码生成工具，能够大大提高开发效率；
2． 工具使用者要求对ibatis和sql比较了解；
3． 在使用过程中对工具进行了完善，这对正式使用工具提供了保证；
4． 与业务层的接口，应该由业务层确定，由持久层实现，而不是由持久层决定；
待解决问题：
1． 持久层的测试该如何进行，才能真的有用；
2． 一些通用功能如分页代码生成，还在开发中；
今天跟SUN的高级工程师有了些交流，感触颇多。首先要谈到它的一个产品（其实不能叫产品）JEF，也就是Java Enterprise Framework。JEF可以说是很多框架和组件的有机结合，有opensource的，有商业的，也有sun自己写的，其实也是SUN在多个大规模项目中不断实践的基础上发展起来的。它通过定义良好的分层和封装，能够提供应用开发非常坚实的基础。下图是JEF的整体架构图：
有机会再进行对它整体架构和各个组件功能的详谈吧。
再谈一谈对真正的系统架构师的认识。JEF的2个主要设计者我都见过了，都是香港人，都温文尔雅，学识渊博，经验丰富。能够聆听它们对软件架构的理解，对项目实际问题的分析和解决，真的是受益匪浅，对自己将来进行设计时思考问题的深度和广度都有很大的提高。这才是真正的架构师！他需要对各种框架，组件都了如指掌，在面对具体的项目需求时能正确的选择最适用的技术；他需要对软件整体架构有清晰的认识和理解，知道在面对实际项目时该使用何种架构，包括thin client还是rich client，with EJB还是without EJB等等；他需要有一种严谨求证的性格，对任何东西不是盲目下结论，而是根据具体的分析和实证进行取舍。。。。。。通往真正的架构师的路还很长，需要经历的项目，需要做的事情还很多。我们不能盲目尊大（拿spring＋hibernate做个小项目就以为很牛），也不能丧失信心（经验和领会都是靠项目做出来的）。我们应该时刻保持向上的心态，去主动参与项目，去沟通，去交流，去总结，去思考。即使将来成不了真正的架构师，我们也可以自豪的说：“我每一步都是踏实的走下来的，我每一个项目都是用心在做的，我的代码都是注释详实，简单易懂，为后来者提供很好的可重用基础的而不是被人咒骂的，我做的是可用的软件而不是垃圾软件。”希望与所有有志于成为真正的系统架构师的同学共勉。
摘要: 项目很小，主体部分也完成的差不多了，但麻雀虽小，五脏具全，我在其中用到了spring的IoC和transaction管理，也用到了简单的AOP功能，同时使用了spring mvc，下面我对它们做一些总结，也跟和我一样刚刚踏入spring大门的兄弟们探讨探讨：
（一）spring IoC探讨
先还是谈谈spring IoC的使用。IoC也就是控制反转，即由容器来调用你的代码，而你不用去使用容器的...
阅读全文
今天忙了一天，收获不小。到公司接到个小项目，需求很简单，时间也很宽松，我就想用spring＋hibernate来做，其实有点杀鸡用牛刀的味道，但我觉得能通过实践来学习spring和hibernate，也还是不错的。
spring和hibernate我也是刚学，各看了本书，然后搞了搞spring的sample，就是那个jpetstore和petclinic，一个是用ibatis，一个用hibernate做persistence层。同时有一个刚进公司的人跟着我做，我也就得先把项目初始化好，写好配置文件，分好包和层次结构，然后放cvs上。既然用spring＋hibernate，配置文件肯定是很多的，我基本是参照petclinic，分了dao, dao.hibernate, model, model.logic, service, web这几个包，配置文件定义了applicationContext.xml，app-servlet.xml(我用spring mvc) , log4j.properties，jdbc.properties, mail.properties，说到spring的配置文件，其实也不复杂，搞懂了它的IoC（DI）和AOP就很容易配了，层次定义清楚，在头脑中对谁ref谁有概念，基本就不大会配错了。错了也没关系，它的log功能强大，定义好log4j，出了什么错都能有详细的记录。我搞spring的sample时就是把这个配置改改，那个删掉，自己写个类，替换它的。。。。。。这样很快就对它的配置文件有了深刻的理解。这次算是我第一个正式用spring的项目，但因为前面在理论上和零星的实践中对它有了较深的认识，也就大大降低了项目的风险（技术预研真的很重要啊！）。
虽然是小项目，但也得规范一下，定好项目计划，统一大家使用的工具和环境，简单交代编程的注意事项，如代码规范，cvs的使用，多写test类等。我们采用eclipse3.1+ myeclipse+tomcat5+mysql作为各自的开发和单元测试环境，上线使用websphere5+db2。我是要求先在mysql上能跑，然后能方便的迁移到db2上的，这样方便进行单元测试，也能在事实上与数据库解耦合，用hibernate很容易做到这一点。
但要能顺利的上线到websphere5，我就没什么把握了，毕竟它还是使用ibm 的jdk1.3，而且很多东西跟tomcat不同，更会不会有什么lib冲突等问题。我先把兼容性测试放在了开发的前面，否则在tomcat上开发好了，websphere不支持或出现难以解决的问题，就麻烦了，严重的可能要推倒重来。因为没在实际项目中使用过spring，周围又没什么人可问（我毕业一年多，没有高手指导，全靠自学和实际项目中领悟），所以有这些疑问也是正常的。不管如何，先把项目在tomcat上跑起来再说。改了一通配置文件，配好tomcat的数据源，往mysql加一个最简单的表（id一个字段），写了2张最简单的jsp（测试spring mvc的multiaction用），一个jsp显示从数据库获得的id。开启和关闭几次tomcat（我比较粗心大意，配错好几处），id就能在页面上显示了。Tomcat上基本配置完成，这也忙了个3、4个小时。
然后就是做兼容性测试了。我们有个websphere的测试环境，先把项目deploy到它上面。测试环境没用ND，我先deploy到server1上，这样能重启应用。Deploy完成，页面都出不来，500错，应用就没起来。先看日志，哇！一堆错。分析日志，好像是先装载的DispatcherServlet, 然后才是ContextLoaderServlet，当然出问题了，不过至少说明它找到了lib下的spring.jar也能work。我使用的Listener而不是Servlet来load context，估计是这个原因导致的，tomcat工作正常，websphere对Listener就不保证先启动了。于是改成使用Servlet，tomcat测试通过，我将改过的web.xml覆盖服务器(这里要覆盖2个地方，一个是应用下的，还有一个config/cells…..下的)， 重启应用，再看日志，还是错。不过这次是先启动ContextLoaderServlet了，但一上来就错了，报错：javax.naming.NamingException: Attempted to use a 4.0 DataSource from a 2.3 (or higher) servlet。这不是spring的问题，呵呵！我用的数据源V4，结果用了j2ee2.3，再改web.xml，头上改成用j2ee2.2，再覆盖，再启应用。这次首页出来了，看日志，一切正常。呵呵！没那么多问题嘛，jdk1.3照样跑最新的spring和hibernate。
今天从零开始把spring和hibernate跑了起来，也算是一次不错的实战，就作为spring+hibernate实战的第一篇吧，接下来几天，我在项目中的体会也会记录下来，当成一个一个系列吧。
摘要: 这篇文章源自刚开发的一个小项目。项目中并未使用hibernate，但我还是要把它放在hibernate栏下。理由很简单，技术是死的，而人是活的，能熟练的使用一项技术不算什么，但能恰当的选择相应的技术，甚至自己想出办法来优雅的解决实际问题，就需要一定的积累了。而这种积累就来源自项目实践和对各种技术其实质的理解。我记得在某个论坛上某人（名字忘了）说过一句话：如果学习hibernate只是学会了怎么ma...
阅读全文