|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-29
matt.u 写道 国外的开源团队正准备在传统开发框架做改革，Grails、Spring Roo、Seam、Play、Lift其实都是大家在对提高开发效率上的尝试。甚至在语言上也在做着改革、Scala、Groovy、JRuby、JPython等的出现也是为了弥补以往使用Java进行开发的不足，所以我们也要吸收新的开发观念，破旧立新。这些才能推动技术的发展。
惭愧，发现自己已经OUT很久了。不过国内除了互联网公司对技术的革新比较重视外，传统的行业软件还是停留国外10年前的水平。 |
| 返回顶楼 | |
|
发表时间：2010-09-29
最后修改：2010-09-29
上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。
|
| 返回顶楼 | |
|
发表时间：2010-09-29
最后修改：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尽量做到有完整的业务逻辑功能，并进行事务控制。 |
| 返回顶楼 | |
|
发表时间：2010-09-29
xhdwell 写道 惭愧，发现自己已经OUT很久了。不过国内除了互联网公司对技术的革新比较重视外，传统的行业软件还是停留国外10年前的水平。
这也是逼出来的啊，“恩，用Java性能好、又安全；Php、Python性能不行，Ruby代码看不懂可能不容易维护；架构要清晰、代码要容易维护；这些需求还不确定，你们先做吧；但是要预留XXX接口，需求更改后要容易扩展；要尽量复用已有的业务逻辑，需求变更后改动要尽量少（实际上经常业务流程和概念都变了）；要做单元测试，最好不能有Bug，另外这个系统功能这么简单，都是些增删查改，一两天应该做得出来吧？开发前好好设计下架构，不要需求一变又改很久！” 在这种情况下，传统SSI、SSH已经不能满足需要了。唯有到处寻找灵丹妙药。 |
| 返回顶楼 | |
|
发表时间：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有何区别呢 其实编程应该尽可能简单，以同样的方式实施同样的过程，不断积累惯用法,将其标准化。 |
| 返回顶楼 | |
|
发表时间：2010-09-29
哎，，LZ 估计刚毕业吧 。这样的架构是很常见的，专为了各种的小系统而设计的 。也能在一定情况下 适应中等系统，不要抱怨说这个架构多麻烦 ，你应该多想想这个架构带来了什么好处 。学的时思想，写代码谁他妈不会写啊！
|
| 返回顶楼 | |
|
发表时间：2010-09-29
等我下一个版本出现的时候，
要把现有版本开源掉 |
| 返回顶楼 | |
|
发表时间：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可能开发量稍微小一点，不过还是觉得有点束手束脚。 |
| 返回顶楼 | |
|
发表时间：2010-09-29
js单独放在一个文件中的好处：
客户端第一次请求后就会缓存，不会找服务器要了 如果你放在jsp文件中: js的代码每次都要由服务器发给客户端，增加网络传输量 service层是用于事务处理拦截处理的，一般的系统需要。你们不需要的话，的确可以省掉这层。 dao层存在也合理啊，每张表一个dao |
| 返回顶楼 | |
|
发表时间：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，其他同以上我说的 |
| 返回顶楼 | |
