|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
其实要代码容易维护，光分层清晰了还不够，更重要是还要做到代码量也少，同时在开发中概念、原则尽量统一，才更容易维护。
只可惜目前传统SSH、SSI项目做不到代码量很少这一点。Repeat Yourself比较多。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
skycray 写道 IcedCoffee 写道 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 这个真的很正常... +1. 挺好的呀，要不还要怎么设计，把功能写在jsp里面，这样一个文件搞定？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
我也觉得是挺正常且目前业界ssh开发常用的分层设计。 楼主对过度设计的理解上可能存在偏差。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 不要service吗？你的业务逻辑在哪写？你的事务控制在哪控制？在action里面控制吗？卖糕的！ |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
lpn520 写道 t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 分开当然要分开，Model-View-Controllor三层，再加上DAO一层，总共四层 Model 就是 Action View 就是 JSP Controllor struts2已经实现了，不需要你实现 DAO ibatis已经实现了，你要做的就是在sqlmap.xml里写SQL就行了 你觉得这四层不够应变你所说的业务逻辑变更吗？ 我想问，你业务逻辑变更了，难道真能可以只修改一层，其它层都不用修改吗？ 最近我也在构思web程序。也一直在挣扎要不要service层。 最啊，action为什么不用作业务，直接调用dao进行处理呢？ 在表现层，我初步设想用jquery,在选grid时，初选jqgrid,发现有他自已的数据格式与后台交互，后来对jqgrid不爽，又改用flexgrid，发现与后台交互的数据格式又有变化。 这是回头发现，如果在action里直接调用dao，发现当表现层变化时，我的业务层也必须根着变化，这时改动的代码量也是很大的。 为了适应这种变化，当然得解藕，现决定增加seriver层。 action层只负责表现层与业务层之间的连接，变换数据格式转换,不作其他处理。 为了少写代码，当然要设计共用的dao与业务层。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
楼主我问你一个简单道理，面向对象代码量比面向过程代码量多是吧。
但为什么人家都用面向对象啊，因为它比较容易维护和扩展。类多是为了让程序一目了然。查找某个类也比较容易定位 |
| 返回顶楼 | |
|
发表时间：2010-09-30
选择技术框架和使用架构,要看业务;也要看市场上的主流技术.
如果业务用主流的技术就行的,我就尽量会用主流的技术框架去做,哪怕比一些偏门的复杂、灵活性差或性能差点都能接受.用主流技术,人好招,随便拉个人来都会.不用怕人员流动(维护都是三年以上的，IT行业，在大部分公司里面，只有少数人能稳定三年吧)。 做开发的个人习惯太严重的,要遵守同一规则,要不你用SSH,我用JSP+JAVABEAN.乱套了.我觉得LZ的框架和我用的没啥大区别,挺正常的,抱怨一下没问题,如果带到公司里面那就不好了. |
| 返回顶楼 | |
|
发表时间：2010-09-30
liupopo 写道 如果就做简单的“增、删、改、查”的话，你们用SSI做什么？？有必要吗？
Struts2里面的Action具体看成Controller还是Model也不是绝对的吧。 学我者生，象我者死。 LZ，你太教条啦。 没有什么教不教条的，我的原则是编程尽可能简单， 框架的作用是什么，框架为你提供了什么，你真的明白吗？ 为什么用SSI？ 我想问你真的理解SSI吗？ 是你用SSI，还是SSI用你？ 既然框架给我们提供了这么多的实现，我们为什么还要往复杂的地方想呢？ 你真想往复杂的地方想，你干嘛不自己写一套，还要用人家框架干嘛？ 我还是那够话，框架给我们提供了便利，而不是复杂度。。。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
搞j2ee开发就是这样，不管怎么样分3-4层是最基础的。
dao层封装数据，manager层封装业务逻辑，service层为外界系统提供服务，然后是表现层，再就是现实的模板视图（jsp,velocity）等。如果做大项目开发的话，这个是必须的，不怎么需要维护的小项目直接JSP都可以，还省得麻烦。 如果想更简单，就用php等脚本语言吧，调试更方便。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
rain999 写道 选择技术框架和使用架构,要看业务;也要看市场上的主流技术.
如果业务用主流的技术就行的,我就尽量会用主流的技术框架去做,哪怕比一些偏门的复杂、灵活性差或性能差点都能接受.用主流技术,人好招,随便拉个人来都会.不用怕人员流动(维护都是三年以上的，IT行业，在大部分公司里面，只有少数人能稳定三年吧)。 做开发的个人习惯太严重的,要遵守同一规则,要不你用SSH,我用JSP+JAVABEAN.乱套了.我觉得LZ的框架和我用的没啥大区别,挺正常的,抱怨一下没问题,如果带到公司里面那就不好了. 其实我也不是抱怨， 我只是想提出来， 看看市场主流开发模型是怎么样的， 感觉今天的收获蛮大的 |
| 返回顶楼 | |
