1、80多个表的系统确实不是大系统；
2、一个表200多个字段，这能说明什么呢？内容项多而已，仅此而已，别告诉我你们把一些控制字段之类的也设计到了一个表里，那么，我又得再怀疑你们的数据库设计能力了。
楼主还是平静下来多研究研究项目管理，多参与参与团队开发比较的好。
1、80多个表的系统确实不是大系统；
2、一个表200多个字段，这能说明什么呢？内容项多而已，仅此而已，别告诉我你们把一些控制字段之类的也设计到了一个表里，那么，我又得再怀疑你们的数据库设计能力了。
1、80多个表的系统确实不是大系统；
2、一个表200多个字段，这能说明什么呢？内容项多而已，仅此而已，别告诉我你们把一些控制字段之类的也设计到了一个表里，那么，我又得再怀疑你们的数据库设计能力了。
个人感觉你们所做的主要是外包项目不知道理解的对不对？不知道在你们的系统中是不是从设计到编码、测试完全都是由你们负责的，如果系统设计不是由你们来负责，那么的确我觉得你们不需要用Struts来进行开发，因为在你们的开发过程就决定了，你们很多的东西无法重用，如果你们是以承接完整的项目，也就是说从设计到编码结束，那么我决定这样才有重用的意义，也才容易实现测试。的确在很多地方Struts可能会不能满足你们快速开发的过程，我觉得Struts等这些框架的目的不是为了减轻开发中的工作量，而是为了让你的系统整体上更加的清晰，提高系统的可扩充性和可维护性的。如果你不需要这些特性那你用Struts的确没有任何的意义。
struts确实舒服.
用struts不在于用它的标签库,也不在于可以节约生产,而是设计思路.
如果你手头上的开发人员都不太熟悉struts大可弃之不用,也不是什么了不起的东西.但是思路可以借鉴,相信也可以写出很优雅的代码,而不用受制于一个所谓的框架.更何况里面的不错的工具类如果你有看的上眼的更是可以原封不动的拿来,加快系统开发.
对于中国做实务的公司来讲100张左右的数据库库表结构不算很多,当然也算是一个大型系统,但是我这里的系统都是动辄1000多张用户表,前提是基于OO的设计库,没有冗余数据出现在一张表.
另外这个问题跟中国人无关.
但是人云亦云的问题比较严重,很多项目经理根本不具备设计的能力,却要引进一个所谓的鸡肋.
本人有信心对开发人员做为期两天的培训（java.struts.dao.....），达到开发效率极为提高？
欢迎联系：
dongqi_zhao@hotmail.com
首先，第一重要的是一个web层的model的问题，model1与model2，二者的特点与优劣不必再比较，相信做过java web应用的人都知道。当解决了视图导航与逻辑定向，和请求集中处理的问题后，继续考虑以下常用的问题。
其次，web层经常使用的技术：防止重复提交，session管理，form表单验证回填功能，i18n国际化......
再次，界面设计编码角度，jsp与taglib的比较。
.....
以上这些问题是我们在进行web开发过程中积累的，凡是有一定java web项目经验的朋友都应该大概知道。这些问题是一些通用的问题，不是每个项目独特的特有的。所以有必要实现一个通用的框架来支持他们。不需要每个项目再过多考虑这些重复的问题，使我们的应用开发的注意力集中到业务上。
好的，你排斥struts可以，但是你你的应用中是不是考虑充分了以上的问题？或者你们自己是不是有对以上问题的成熟的解决方案？如果有，你的比struts的好，好的，扔struts到一边去。如果没有，好的，看看现有的相对成熟的框架，webwork，struts，Tapestry等等web mvc框架，每种都有自己的特点和有缺点。可以先拿来一个用，熟悉了，再尝试其他的，然后比较，然后可以有自己的mvc框架，你的可以比它的实现更完美，更好，更能解决你遇到的实际问题，那么你是好样的。你说你们开发应用使用struts复杂，是因为你们的应用本身不需要struts为你提供的那些服务，你为什么用struts呢？连自己为什么用都搞不清楚，有什么资格说它好与坏？但是当你的应用真正需要这些服务的时候，你会发现它确实是个好帮手。什么东西都有好的一面与坏的一面，我们利用的是他的好的一面，不是坏的一面，这点请搞清楚。
我们说一样东西好与坏不能停留在外观的底层的认识，只有你真正了解它才有资格发言。你这样不负责任的浮躁，甚至是口出狂言毫无益处。大家是搞技术的人，凡事讲究以理服人，以技术服人，说技术就说技术，不必上升到民族，不必喊爹骂娘。