“过度设计”之真实例子

其实楼主这样的人太多了，团队里最怕的也是这样的。
你站在一个coding的角度去评判人家站在架构的人设计的东西，就像小学生评研究生作品一样。
你考虑的莫过是你完成一个task的时间问题。架构师考虑的是整体性，要考虑开发规范，业务需求改变后的成本，运维人员的工作，上线和二次开发的成本，项目对开发人员的依赖度等等等.....
所以好的架构不是让coding人员叫好的，而是让其他人叫好的。

我们公司没有使用，只是在对grails做调研时我用了一下，我的确没有调整jvm参数，但我看了下热部署的日志以及出现错误的问题，貌似grails（或者说grails的tomcat插件）在热部署时，把相关的GSP都删了，然后再重新发布一次。这个过程在我机器上要个5、6秒吧。不是太让人接受。

我也碰到grails里面的service问题，因为事务是在Service层上的，所以要求做增删改时都应该要使用Service层吧（我看的文档和Grails社区的相关文章，都是这样建议的）。如果要图简单，就需要再Controller直接调Domain的find方法，又要调Service里面的save方法，这样就感觉有点混乱，概念不太一致。

我觉得最好事务可以透明的加到Domain上面。当然有些Rails Like框架是把事务加到Action上面的。

个人觉得MVC教给我们的是一种思想,大家对现实世界都有个认识,有的人认为这样合适,有点人则认为不合适,引用一句著名语言:没有调查就没有发言权,不知道lz有没有真正对自己公司手下的程序员做过调查,看看大家的想法是怎么样啊?如果大家都认为不合适,再问:为什么不推翻了,重新设计,
会有很多回答:
1.要快速提交市场,没时间重新设计,没经费
2.老板不会同意,不会带来显著效益,公司不是你的试验田,你必须有十足的把握,
能在多长时间完成你的设计,你的设计能给公司开发带来多大好处?
这些问题你问过自己了吗?看了半天,lz都是一些细枝末节的讨论,什么文件要几个,实在没必要,如果你真想改变这个现状,建议你搞个试验,有充分的研究和讨论后再发出来,给整个java开发世界一个新的思路.
说的不足之处,大家指教,谢谢大家.

如果用hiberante等ORM框架其实没必有DAO了，
可以 interfaceService abstractService  HibernateServiceImpl(或是IbatisServiceImpl)
如果用到泛型哪这个Impl也可以去掉了.
这样代码量也不会有多少，而且可以组织复杂的逻辑，在Action中最好还是不要直接写持久层的代码，系统复杂的性况下还是需要Service的。

DB不只是简单的CRUD，还有复杂的查询。。。

复杂查询哪就教给 ibatis或是jdbc都可以啊，hibernate也是可以本地sql~

说到底，楼主还没理解mvc真正的含义，丢恒生的脸啊。

是啊，但是写道DAO里面相对来说好一点吧。

不管楼主的想法符不符合实际情况，也不管这种方式正不正确，但我觉得楼主这种怀疑和求知的态度值得鼓励。

走出java这一小步，你会发现还有很大一块天。

我觉得怎么都行，还是看团队约定吧。