一种一站式的Java Web框架的设计和实现

可能是我们的开发环境限制，因为我们这边中大型项目较多，100-400人月（大项目分成中小项目），一般限制在jdk1.42，因为应用服务器对jdk版本支持不够，如Websphere6.0和Weblogic8.14。另外，项目组成员能力参差不齐，我们希望最大程度节省培训和技术带来的成本，达到开发成本和时间的最优。不过，要是可以用jdk1.5，譬如jboss4.0就对它支持很好，这样用annotation和xdoclet也确实很不错，但是，由于我的对象是map弱类型的，这两项技术可能都用不着。
在维护map结构时，我们的建议是，对照jsp页面和hbm.xml文件，因为BO里面的数据直接来源于jsp页面的表单(以及get请求)。
而且，在RoR里，大概也没有你说的一目了然吧，我觉得这种POJO只是大多数人用Java做Web开发形成的习惯罢了，未必在所有情况下都是最好的选择。

注意，我这儿的hbm.xml文件里面都是plain结构，删掉了所有关联，一个中大型项目所有的hbm.xml完全由一个人维护一点也不难。

想想在这种环境下你会怎么做：你在一家大型IT外包公司，并且你是项目的technical leader，忽然来了一个中型项目，100人月左右，临时调来公司暂时闲着的开发人员，然后期望着这个项目在三个月后上线。

这应该是一个对管理和技术都有挑战性的主题，说说你们的高见吧，先谢谢了！

就说我想到的吧：
1、培训 视成员能力层次，持续的培训，每周三次左右，每次一个半小时；以及对共通出现问题不定时半小时左右讨论和培训
2、做一个简单的集成框架，让人人都容易理解和开发。
3、尽量撇开公司重量级的CMM5，采取一些轻量级的过程管理，如Agile UP
..........

我们的情况类似，大致看了一下其他人的问题，有些在我这里是解决了的。
我们不仅考虑技术，还要综合考虑管理因素，特别是大型项目。
其实国内的软件开发都是做工程的，但是都用做研究的方式来做事情，陷入技术泥潭，却始终只是跟在别人屁股后面“学习”。

你把它叫做framework,我把它叫做platform,
这个platform=framework+supporting tools

这个是经过几个大型项目实践的（功能点在1万左右）

请先看
http://www.iteye.com/topic/51522
40楼
但是那里写的思路不是很清

我的msn：
basicbest@hotmail.com

我很希望听你仔细从头描述一下你的平台。如：平台的动机、目标；利用你的平台如何实现一个基本CRUD功能等。

我也有类似的经验。Msn你何时在线？

非常好，我也加了你了.
17日10：30-11：30可能有空.

最近也在为这个问题感到苦恼~
这也是一个老生常谈的话题
系统的可扩展性和代码的重复性的问题
下了看看楼主是如何解决的，看完了再来讨论。

是什么决定了系统的可维护性和扩展性，也是我现在在思考的问题。

我现在看到两种切实可行的方案：
1、基于Plugin的松耦合架构
主要参考：
Openfire和spark的架构(我的二次开发经历)
OSGi
2、基于事件和消息路由的松耦合架构
主要参考：
http://www.infoq.com/articles/dynamic-routing-using-spring
PageFlow
WorkFlow

另外，我想很多人不赞成我的那个方案，是因为它太不OO了，下面是我思考：

我觉得，现在流行的Webwork＋Spring＋Hibernate都是偏重分层，Spring里面的业务一般也是Transaction Script方式（《Patterns of Enterprise Application Architecture 》），
而要采用Domain Model，那么会弱化分层（怎么持久化并不关键），我不知道大家怎么去折中这种问题。
不知道大家对《Hibernate in Action》中的Auction例子怎么看法，不过Gavin King没有告诉我们怎么把他的Domain Model和Spring、Webwork优雅的集成。而在without EJB附带的，那个spring-jpetstore例子和Auction是冲突的。

我发现，要是按照领域建模，从需求分析的领域模型，逐渐过渡到设计模型，一次次迭代，两种类图很难match，因为在分析阶段的model里面有方法，在真正实现时，都移到了DAO或Service里面，而DAO和Service是无状态的，Domain其实已经不是Domain，而是Entity。难道领域模型只用来做描述、理解、分析业务？
至少，上面的方式在我经历过的一个大型业务系统是成功的（1200万RMB，50万行Java代码），而且这样做也不影响系统的可维护性。