|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-29
最后修改：2010-09-30
张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 |
| 返回顶楼 | |
|
发表时间：2010-09-29
lpn520 写道 xhdwell 写道 lpn520 写道 wangking717 写道 真想看看那个HELLOWORD分8个的代码，让我见识一下。
让你见识一下传说中的8个文件： 前端 helloWord.jsp //页面文件，不用说了 helloWord.js //javascript文件 Struts的Action，就叫动作层吧 HelloWordAction.java //Action类文件，客户端请求到这个类上 业务层 HelloWordService.java //业务接口， 还用了一套传说中的“面向接口编程” HelloWordServiceImp.java //业务实现类，实现上面定义的接口 DAO层 HelloWordDao.java //数据操作类，关于HelloWord业务的数据操作都在这里 HelloWord.java //HelloWord表的ORM的对象 HelloWord.xml //HelloWord表操作的SQL语句，ibatis的sqlmap 看了这个结构觉得已经很简单了啊。是最正常的分层啊。兄弟，建议你多学点设计思想。就不会问这样的问题了。 我只能说这是一个广泛的分层，至少已经用了10年了吧，10年前可能没这么多框架，那是合理的，但现在这么多框架干嘛的，不就为了让你简化开发，那为么框架用起来了，而设计的思路却还是跟10年前一样呢 如果是为了单独的功能的话，确实没有必要。如果是抽象服用的话，那么这个就是你的误读了。但是，我觉得一般不会出现前者。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
Durian 写道 这事儿遇到过，一个大博士做的设计，繁冗的厉害。
这个架构师的表达能力还很强，理论很深，所以，基本上把最简单的问题用当今最先进高深的技术实现了。不复杂不足以表达他的雄心壮志。 一语中的 就像刚学了新东西恨不得全部用上 新生的鸟儿羽翼未丰就想飞 不过在这样的公司好混日子 |
| 返回顶楼 | |
|
发表时间：2010-09-30
不就分了3个层么。
这也叫设计过度？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
mercyblitz 写道 lpn520 写道 xhdwell 写道 lpn520 写道 wangking717 写道 真想看看那个HELLOWORD分8个的代码，让我见识一下。
让你见识一下传说中的8个文件： 前端 helloWord.jsp //页面文件，不用说了 helloWord.js //javascript文件 Struts的Action，就叫动作层吧 HelloWordAction.java //Action类文件，客户端请求到这个类上 业务层 HelloWordService.java //业务接口， 还用了一套传说中的“面向接口编程” HelloWordServiceImp.java //业务实现类，实现上面定义的接口 DAO层 HelloWordDao.java //数据操作类，关于HelloWord业务的数据操作都在这里 HelloWord.java //HelloWord表的ORM的对象 HelloWord.xml //HelloWord表操作的SQL语句，ibatis的sqlmap 看了这个结构觉得已经很简单了啊。是最正常的分层啊。兄弟，建议你多学点设计思想。就不会问这样的问题了。 我只能说这是一个广泛的分层，至少已经用了10年了吧，10年前可能没这么多框架，那是合理的，但现在这么多框架干嘛的，不就为了让你简化开发，那为么框架用起来了，而设计的思路却还是跟10年前一样呢 如果是为了单独的功能的话，确实没有必要。如果是抽象服用的话，那么这个就是你的误读了。但是，我觉得一般不会出现前者。 这么说吧，楼主的方向没有错，不应该过度设计。不过理解有偏差，抽象是要的，解耦合也是必要的。不过不应该拘泥于形式，不是说一定要上述的模式。架构都需要灵活性，何必拘泥于形式。这也是软件编程思想的误导和悲哀，因为那些东西是引导你设计，而不是为了铺路。设计模式如此，软件开发方法论也如此。 还有一点，看了这么多，谈到分层这个东西是最基础代码级别。这个是设计，和架构很有很大的距离。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
感觉现在什么SSH，SSI几乎成了开发的经典教义，你不这样做，或者不完全这样做就是背经离道。
个人感觉该解耦的时候接口，该分层的地方分层，都是根据实际情况灵活决定的。有必要动不动就加这么一大堆东西和配置文件进来吗，难道不能根据项目实际需要用点简单直接的办法来处理sql、事务啥的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 jasph77 写道 构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。 架构师也是个人，他的架构必然也有不完美地方。 最讨厌那种，整天说这个不好、那个行，自己又没解决方案。 给你看看我之前做的解决方案，同样“添加删除修改查询”，同样是Struts2+Spring+iBATIS+ExtJs 前端 helloWorld.jsp //用过Ext的都知道，页面是不需要写HTML代码的，所以helloWorld.js直接可以省掉，直接把js写在jsp文件里，还有用EXT直接使用原生态的，封装一层只的很恶心 业务层 HelloWorldAction.java //struts2的Action，本身就是动作的意思，为什么它不叫Controllor呢，因为控制类已经在它内部封装好了，你实现了Action接口，只要在类里写业务就可以了，再加上struts2每个请求可以对应到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 看了lz这段话，觉得lz资历和经验看样子比较浅，还是虚心点好。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
|
| 返回顶楼 | |
|
发表时间：2010-09-30
lz说自己做java也有4年了，那么这4年你没有遇到这样的架构吗？
这样的架构应该说随处可见啊... 可是为什么4年之后的今天，你突然会站出来说他过度设计？ 很令人费解... |
| 返回顶楼 | |
|
发表时间：2010-09-30
southgate 写道 张口闭口解耦
why解耦？ 普通业务写在action里头有什么不好，清晰 简单 很长的业务 搞一个manager分离出去 重复地业务 搞一个common分离出去 把重用和解耦挂在嘴边的同学，你解耦过多少次 上周参加了一个接力短跑比赛，总共10个人参加，其中有8个人一步都没跑，接了棒子以后就传递给下一个人了。问他为什么这么干，他说他是专门跑山地的，不能跑平原。我说那你别参加啊，他说，我必须的参加，这样可以提高我们团队适应各种情况的能力。 经典 哈哈，确实经典中的经典 |
| 返回顶楼 | |
