“过度设计”之真实例子

　　我刚到了一家新公司，公司给我的感觉很不错，不过当开始做第一个项目时便有过度设计的嫌疑，项目不大，基本就实现CURD的功能，用struts2+spring+ibatis+extjs。拿我开发的一个简单的功能来讲，就花了大概一周，如果采用简化的技术，实际上可能只需要一两天。

　　设计太多的分层，以及偶和性太高，添加或修改一个模块太困难了，而且还不知道会不会影响到其它模块。按照项目定义的规范做法，写一个Hello world，创建的代码文件个数必须达到8个！！！！

　　过度分层已经成为过度设计的一个典型。项目经理说，这是另一个项目的架构直接搬过来用的，我们做一下架构上的优化。

　　其实本来就没有什么优化，原来本就是简单的东西，为了显示技术，搞得特复杂。现在所谓的优化，实际上回归质朴而已。

　　记得OSI7层模型就有过度设计嫌疑，可以去看一下现在的教材，都没有用OSI作为例子，尤其没有专门讨论会话层。

　　如何防止过度设计，最好办法就是使用敏捷编程，他的思路就是刚刚好就行，如果有问题，再重构。另外我自己目前的实践方法就是多编程，少设计，好像也能避免。因为当你的任务主要是写代码的时候，你绝不会去写8个类来完成一个helloworld。

　　其实，我所说的就是开发原型，也是《敏捷开发方法》里提到过的方法。

评论

110 楼 zdmcjm 2010-09-29  

别争了，都来用grails吧，正常人用过grails后，都不会再想用java开发所谓的企业级应用了。

109 楼 2022228 2010-09-29  

2022228 写道

js单独放在一个文件中的好处：
客户端第一次请求后就会缓存，不会找服务器要了

如果你放在jsp文件中:
js的代码每次都要由服务器发给客户端，增加网络传输量

service层是用于事务处理拦截处理的，一般的系统需要。你们不需要的话，的确可以省掉这层。
dao层存在也合理啊，每张表一个dao

108 楼 lgc653 2010-09-29  

喜欢简单直接的约定和结构，讨厌所谓的设计模式和过多配置文件。再大的项目也是由小项目组成的，做好够用的契约和分层一样很好维护，也更容易理解。

107 楼 2022228 2010-09-29  

matt.u 写道

matt.u 写道

2022228 写道

引用

DAO都抽象成公共的，不需要自己定义DAO

难道就没有复杂点的查询？

难道你的查询都是复杂的？

况且公共DAO也可以使用Native Sql。

所有native sql都写这个dao里面？

106 楼 teclogid 2010-09-29  

楼主，首先我要说你连最基本的事务边界可能都不清楚。Service层都没有，按你思路做出的系统，绝对存在数据的不一致性。

为什么要用接口？
这方面的好处，我就不说了，自己看书去。

Ext为什么要封装？
这样可以统一界面，如果你每个人都按自己一套创建一个panel，当需要在panel上都加一个按钮什么的，你需要改多少个jsp？人家只要改一个包装的js。任何项目都会用Ext.extend来封装自己的项目组件。

为什么js要提出到单独文件？
1.、编辑器友好，你在jsp里能代码提示吗，能校验吗？
2，方便压缩，js和html合并从来都不是什么问题，弄个ant任务就行了。

分的多不是问题，关键是分割都是必要的，按你的思路，弄一个jsp就写一个系统得了，来回请求这个jsp，用标志位判断执行哪一段，那岂不是超级简单了？这样你就爽了？

105 楼 lpn520 2010-09-29  

bonny 写道

引用

首先我再次声明，目前在这么庞大的设计架构背后，只是一个小小的管理系统， 用的是SSI+EXT
JSP里应该避免写任务的JS， 那我JSP里写什么呢， 用了EXT， JSP里一般HTML都不用写。
Action存在的意义其实是动作，可以理解成Model，而非控制（Controllor），可以去看struts2文档，它就是让你写业务
service层其实可以写成抽象Action，写一些公共的业务逻辑，实体Action继承这个抽象的Action，不是更好吗
DAO层其实已经在ibatis里实现，ibatis就是项目中的DAO层，它的每一个操作，都是实现对数据库直接操作的一层，你的SQL都写在XML里， 这跟我们以前用JDBC手动写的一层DAO有何区别呢

其实编程应该尽可能简单，以同样的方式实施同样的过程，不断积累惯用法,将其标准化。

1，使用OPOA，只有一个jsp，一个页面一个js。
2，如果用ext，不要用struts，用springmvc直接responsebody
3，其他同以上我说的

不错，我其实就是用SpringMVC， 因为struts太有名了，所以 提出来说而已

104 楼 lpn520 2010-09-29  

JavaLanguageFun 写道

哎，，LZ 估计刚毕业吧 。这样的架构是很常见的，专为了各种的小系统而设计的 。也能在一定情况下 适应中等系统，不要抱怨说这个架构多麻烦 ，你应该多想想这个架构带来了什么好处 。学的时思想，写代码谁他妈不会写啊！

不好意思，我可能不是你想的那种人，呵呵，思想谁都在看，学JAVA学的是什么呢，还不就是思想，有学算法吗，没有，有学数据结构吗，没有， 只有那一开始的23种模式，再加上无敌的SSH，然后写个HelloWorld建8个类， 到头来却只发现，原来自己做的只不过是 添加删除修改 而已

103 楼 matt.u 2010-09-29  

matt.u 写道

2022228 写道

引用

DAO都抽象成公共的，不需要自己定义DAO

难道就没有复杂点的查询？

难道你的查询都是复杂的？

况且公共DAO也可以使用Native Sql。

102 楼 matt.u 2010-09-29  

2022228 写道

引用

DAO都抽象成公共的，不需要自己定义DAO

难道就没有复杂点的查询？

难道你的查询都是复杂的？

101 楼 evanz 2010-09-29  

Keep it simple and stupid

100 楼 2022228 2010-09-29  

引用

DAO都抽象成公共的，不需要自己定义DAO

难道就没有复杂点的查询？

99 楼 bonny 2010-09-29  

引用

首先我再次声明，目前在这么庞大的设计架构背后，只是一个小小的管理系统， 用的是SSI+EXT
JSP里应该避免写任务的JS， 那我JSP里写什么呢， 用了EXT， JSP里一般HTML都不用写。
Action存在的意义其实是动作，可以理解成Model，而非控制（Controllor），可以去看struts2文档，它就是让你写业务
service层其实可以写成抽象Action，写一些公共的业务逻辑，实体Action继承这个抽象的Action，不是更好吗
DAO层其实已经在ibatis里实现，ibatis就是项目中的DAO层，它的每一个操作，都是实现对数据库直接操作的一层，你的SQL都写在XML里， 这跟我们以前用JDBC手动写的一层DAO有何区别呢

其实编程应该尽可能简单，以同样的方式实施同样的过程，不断积累惯用法,将其标准化。

1，使用OPOA，只有一个jsp，一个页面一个js。
2，如果用ext，不要用struts，用springmvc直接responsebody
3，其他同以上我说的

98 楼 2022228 2010-09-29  

js单独放在一个文件中的好处：
客户端第一次请求后就会缓存，不会找服务器要了

如果你放在jsp文件中:
js的代码每次都要由服务器发给客户端，增加网络传输量

service层是用于事务处理拦截处理的，一般的系统需要。你们不需要的话，的确可以省掉这层。
dao层存在也合理啊，每张表一个dao

97 楼 matt.u 2010-09-29  

lpn520 写道

首先我再次声明，目前在这么庞大的设计架构背后，只是一个小小的管理系统， 用的是SSI+EXT
JSP里应该避免写任务的JS， 那我JSP里写什么呢， 用了EXT， JSP里一般HTML都不用写。
Action存在的意义其实是动作，可以理解成Model，而非控制（Controllor），可以去看struts2文档，它就是让你写业务
service层其实可以写成抽象Action，写一些公共的业务逻辑，实体Action继承这个抽象的Action，不是更好吗
DAO层其实已经在ibatis里实现，ibatis就是项目中的DAO层，它的每一个操作，都是实现对数据库直接操作的一层，你的SQL都写在XML里， 这跟我们以前用JDBC手动写的一层DAO有何区别呢

其实编程应该尽可能简单，以同样的方式实施同样的过程，不断积累惯用法,将其标准化。

每个决定架构的人也许对分层的理解不一样，Action里面我通常要求只做简单得跳转，逻辑在Service或Biz里面（事务放在这上面），DAO都抽象成公共的，不需要自己定义DAO。Domain里面封装只跟自身有关的不涉及持久化的简单处理逻辑。

我们使用SSI，按照这个分层下来，加上单元测试，我发现程序员在开发一个增删查改功能时，基本上需要在7、8个文件中切换，严重影响开发效率。
几个小时下来，估计一个增删查改加测试还没搞定。
就算有脚手架生成查询和CRUD代码，感觉要维护的东西还是很多。
用SSH可能开发量稍微小一点，不过还是觉得有点束手束脚。

96 楼 jasph77 2010-09-29  

等我下一个版本出现的时候，
要把现有版本开源掉

95 楼 JavaLanguageFun 2010-09-29  

哎，，LZ 估计刚毕业吧 。这样的架构是很常见的，专为了各种的小系统而设计的 。也能在一定情况下 适应中等系统，不要抱怨说这个架构多麻烦 ，你应该多想想这个架构带来了什么好处 。学的时思想，写代码谁他妈不会写啊！

94 楼 lpn520 2010-09-29  

aws 写道

lpn520 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

给你看看我之前做的解决方案，同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs

前端
helloWorld.jsp       //用过Ext的都知道，页面是不需要写HTML代码的，所以helloWorld.js直接可以省掉，直接把js写在jsp文件里，还有用EXT直接使用原生态的，封装一层只的很恶心

业务层
HelloWorldAction.java     //struts2的Action，本身就是动作的意思，为什么它不叫Controllor呢，因为控制类已经在它内部封装好了，你实现了Action接口，只要在类里写业务就可以了，再加上struts2每<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>个请求可以对应到Action的一个个方法上，所以万恶的HelloWorldServer.java和HelloWorldServerImp.java可以去掉了

DAO层
再讨论一下DAO层，我们用了ibatis框架，他本身就是个DAO层的实现，你每个SQL调起来就像调用DAO里的每个方法一样，所以HelloWordDao.java就可以去掉了，像HelloWordDao.java里的每个方法就一条代码，有意思吗
所以只要下面两个文件就可以了
HelloWord.java          //HelloWord表的ORM的对象
HelloWord.xml           //HelloWord表操作的SQL语句，ibatis的sqlmap

JSP里应该避免写任何的JS

Action存在的意义是控制前端和后端的数据交互和数据校验，在里面写那么多业务逻辑代码算什么

service是实现业务逻辑的一层，负责逻辑和组织调用DAO里面的方法

DAO是实现简单逻辑和对数据库直接操作的一层，这个是可以泛型化的

你要真想简单，那么直接都写在JSP里直接调用数据库得了

首先我再次声明，目前在这么庞大的设计架构背后，只是一个小小的管理系统， 用的是SSI+EXT
JSP里应该避免写任务的JS， 那我JSP里写什么呢， 用了EXT， JSP里一般HTML都不用写。
Action存在的意义其实是动作，可以理解成Model，而非控制（Controllor），可以去看struts2文档，它就是让你写业务
service层其实可以写成抽象Action，写一些公共的业务逻辑，实体Action继承这个抽象的Action，不是更好吗
DAO层其实已经在ibatis里实现，ibatis就是项目中的DAO层，它的每一个操作，都是实现对数据库直接操作的一层，你的SQL都写在XML里， 这跟我们以前用JDBC手动写的一层DAO有何区别呢

其实编程应该尽可能简单，以同样的方式实施同样的过程，不断积累惯用法,将其标准化。

93 楼 matt.u 2010-09-29  

xhdwell 写道

惭愧，发现自己已经OUT很久了。不过国内除了互联网公司对技术的革新比较重视外，传统的行业软件还是停留国外10年前的水平。

这也是逼出来的啊，“恩，用Java性能好、又安全；Php、Python性能不行，Ruby代码看不懂可能不容易维护；架构要清晰、代码要容易维护；这些需求还不确定，你们先做吧；但是要预留XXX接口，需求更改后要容易扩展；要尽量复用已有的业务逻辑，需求变更后改动要尽量少（实际上经常业务流程和概念都变了）；要做单元测试，最好不能有Bug，另外这个系统功能这么简单，都是些增删查改，一两天应该做得出来吧？开发前好好设计下架构，不要需求一变又改很久！”

在这种情况下，传统SSI、SSH已经不能满足需要了。唯有到处寻找灵丹妙药。

92 楼 jasph77 2010-09-29  

aws 写道

lpn520 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

给你看看我之前做的解决方案，同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs

前端
helloWorld.jsp       //用过Ext的都知道，页面是不需要写HTML代码的，所以helloWorld.js直接可以省掉，直接把js写在jsp文件里，还有用EXT直接使用原生态的，封装一层只的很恶心

业务层
HelloWorldAction.java     //struts2的Action，本身就是动作的意思，为什么它不叫Controllor呢，因为控制类已经在它内部封装好了，你实现了Action接口，只要在类里写业务就可以了，再加上struts2每<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>个请求可以对应到Action的一个个方法上，所以万恶的HelloWorldServer.java和HelloWorldServerImp.java可以去掉了

DAO层
再讨论一下DAO层，我们用了ibatis框架，他本身就是个DAO层的实现，你每个SQL调起来就像调用DAO里的每个方法一样，所以HelloWordDao.java就可以去掉了，像HelloWordDao.java里的每个方法就一条代码，有意思吗
所以只要下面两个文件就可以了
HelloWord.java          //HelloWord表的ORM的对象
HelloWord.xml           //HelloWord表操作的SQL语句，ibatis的sqlmap

JSP里应该避免写任何的JS

Action存在的意义是控制前端和后端的数据交互和数据校验，在里面写那么多业务逻辑代码算什么

service是实现业务逻辑的一层，负责逻辑和组织调用DAO里面的方法

DAO是实现简单逻辑和对数据库直接操作的一层，这个是可以泛型化的

你要真想简单，那么直接都写在JSP里直接调用数据库得了

我原则很简单：
1、sql语句只能出现在DAO里面
2、DAO尽量简单，不要有太多的逻辑判断
3、Action只做跳转、json xml生成，无业务逻辑判断
4、service尽量做到有完整的业务逻辑功能，并进行事务控制。

91 楼 bonny 2010-09-29  

上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。