“过度设计”之真实例子

有时候有弄明白自己到底想要什么？
为什么要这么写？
不要为了action而action，为了service而service

J2EE很多时候告诉企业开发，要这样做、可以这样做。
而很多人没去考虑 为什么这样做，这样做对自己有什么好处。

架构师的思想没有被好好的继承下去，只会依样画葫芦。

架构师在架构系统的时候 没有考虑的问题 没有及时的发现，被及时更正。

系统架构不单单是架构师的事情，是整个项目组或者整个团队集体思想的结晶。

Helloworld这个例子不太清楚 这个Helloworld是Entity吗，按照这个架构action service其实要不了几个文件的。
dao因为和Entity一一对应可能会多点.如果有泛型dao可以继承 EntityDAO的代码会很少。
action的代码都是逻辑跳转代码也会很少。
service完成业务逻辑代码会多些。
分配任务的话干脆就固定一个人专门负责action一个人专门负责dao，其他人都做jsp和service

一般在系统架构阶段，采取集体创作方式。
1、头脑风暴阶段：充分分析业务，在业务基础上架构师提出自己的设计，说明设计原因。
2、设计讨论阶段：各成员 提成对架构的设计提出自己的意见。架构师采纳，如果不采纳说明理由。有争议以架构师说了算。
3、设计实现阶段：在大家通力合作下完成系统构架。

这样架构师的思想得以继承船舶，各成员才能得以发挥。

我一直避免谈，这样写是对的，那样写是不对的。
是要符合团队开发习惯，容易维护，加快、保证项目进度就是好的架构。

终于看完了，发现强人太多了，压力很大很大

系统架构原则很简单：
1、sql语句只能出现在DAO里面 （到处sql太乱）
2、DAO尽量简单，不要有太多的逻辑判断 （为了能更好的复用性）
3、Action只做跳转、json xml生成，无业务逻辑判断 （Action里有事务，不好控制）
4、service尽量做到有完整的业务逻辑功能，并进行事务控制。 （业务逻辑上的通用性，如：增加用户，我可以form表单提交、也可以用websevice调用，通过ejb访问）

这个还好吧
javaeye有几个神贴，
记得好像是 从03年 一直讨论08年 整个帖子横跨5-6年
讨论领域模型。

最后明白一个道理，婆说婆有理 公说公有理。
适合自己的就是行。

杭州的javaeyer蛮多的，有机会出来聊聊，站内短信我。

最后广告上智*联搜索：‘省档案事务所’，最近公司大量招人java,delphi

虽然很久没写java了，朋友的帖子还是说2句。
虽然我觉得这个整个就一水贴。

一直以来我对框架很反感，为什么呢，因为我觉得其实开发经常会遇见不一样的情况，那么自然设计不一样。
很奇怪了，凭什么每次我们开放都要弄杂七杂八这个那个的框架。早年间，做C++和C的怎么都是库来完成底层的东西。没什么框架不框架的。
就算是微软的DOTNET。那种Framework的形式不是也蛮好么。
好吧最早的设计模式都只是教我们在怎么去好好设计。这些框架很奇怪的实现一堆模式，然后告诉我们它是对的，我们应该在做项目的时候用框架强上，你这个又不是万能产品，每次我配置一大堆，写一大堆像脚本一样的语言有意思么。凭什么你的设计就是对的，你了解我项目的需求么。

我觉得我没发言权，只是发现身边的同事，很多人都很习惯这种东西，配置一大堆，对架构不清楚。
真觉得很奇怪了。

我一直在想有没有通过一些建站系统成立起来的大型网站，它们对这些建站系统没有改造，没有修改的，有这么一种系统可以万能通吃的。

我们的架构师，远离框架，设计出来的东西是否符合架构。我是真的不明白。
那种类库，封装部分功能，除了接口一切都是黑盒的真的不好么。框架做的就对么？

我想一个写过几年程序的人也会明白，SQL不要到处有，变量定义要谨慎，等等框架在做的事。如果没有还是请他回家吧。

没有银弹，可是我们好像在拿框架当银弹用，觉得换人就像换电脑。

我们的稍好点，我们用的一个servlet处理多个action，更加acttype  调用不同的方法，楼主说的这种设计还是很常见的了，我看了常见的例子都是这样的，别奇怪，都是为了也许永远用不上的所谓的扩展性。

其实去看看GOOGLE这样的公司，养团队而不做技术标准，做产品而不做业界规范，要程序员而不要业界大事，设计师都写代码。确实比较符合软件公司。

框架，脱离开发的设计都不人性化，都只是工商管理课程里面死记硬背的东西。人性化的公司有竞争力。