|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
IcedCoffee 写道 lz说自己做java也有4年了，那么这4年你没有遇到这样的架构吗？
这样的架构应该说随处可见啊... 可是为什么4年之后的今天，你突然会站出来说他过度设计？ 很令人费解... 呵呵，从我做JAVA开始，我就自己设计，从来都是带别人做，没有别人带我做过，我也在虚心学习，我也想知道，市场主流开发是怎么样的 |
| 返回顶楼 | |
|
发表时间：2010-09-30
分层的结果是简单问题复杂化，复杂问题简单化，写个Hello world你也不用分几层吧
|
| 返回顶楼 | |
|
发表时间：2010-09-30
幽梦新影 写道 分层的结果是简单问题复杂化，复杂问题简单化，写个Hello world你也不用分几层吧
分层是规范，代码要统一，必须这么写，方便以后维护和扩展（架构师原话） |
| 返回顶楼 | |
|
发表时间：2010-09-30
lgc653 写道 喜欢简单直接的约定和结构，讨厌所谓的设计模式和过多配置文件。再大的项目也是由小项目组成的，做好够用的契约和分层一样很好维护，也更容易理解。
设计模式本来就是让程序的层次逻辑更简单明了，这并不冲突。但别一拿到什么问题都往工厂模式，策略模式上去套。在用设计模式之前先要想清楚为什么要用，能解决什么问题。 |
| 返回顶楼 | |
|
发表时间：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. 确实很正常啊，如果需要事务的话，事务一般都在service层。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
jasph77 写道 系统架构原则很简单：
1、sql语句只能出现在DAO里面 （到处sql太乱） 2、DAO尽量简单，不要有太多的逻辑判断 （为了能更好的复用性） 3、Action只做跳转、json xml生成，无业务逻辑判断 （Action里有事务，不好控制） 4、service尽量做到有完整的业务逻辑功能，并进行事务控制。 （业务逻辑上的通用性，如：增加用户，我可以form表单提交、也可以用websevice调用，通过ejb访问）  这不是过度设计吧，是正常的系统分成逻辑。
|
| 返回顶楼 | |
|
发表时间：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. 这不是很正常吗？鄙人没看出有何不妥。 架构的好坏不能以文件的多寡来衡量。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
这个很正常，按楼主的说法，如果硬要把前端页面也算一层的话，也顶多四层而已。
参照mvc模型，你这个结构顶多多了一个服务层。 要有8个文件主要是多了service的接口，和dao的接口。 面向借口编程我想没有什么可以诟病的。 如果仅仅说服务端的话，这是一个很正常的三层设计模式。 action用来做控制转发是有必要的。有些复杂的逻辑如果你写在action里面，同样会导致可读性的问题。 action不仅仅是控制转发，有时候还会承担一些数据的处理工作。 service层仅仅用来做业务逻辑是很合理的。 js单独放文件时很有必要的，项目的后期维护，如果团队更换或人员更换，在html里的js会导致可读性很差。 当然也要保证你的js文件结构合理，功能分类比较合理。 封装ext,或者封装jquery我也认为没有道理，我觉得国内的编码人员很难达到人家的水平，也许封装只是导致更多问题的出现而已。 如果你们的项目如果是小型项目的话我想简化设计是可以的，如果你的项目要不断扩展和维护，你的简化会导致很多后期问题。 这个结构我可以很明确的告诉你，华为几千万美金的电信项目，结构分层和这个差不多，甚至多出一到二层。 项目分层而言，我觉得这个很正常，但是具体情况要看你们具体的项目情况，别一棍子把人打死了。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
xhdwell 写道 jasph77 写道 构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。 架构师也是个人，他的架构必然也有不完美地方。 最讨厌那种，整天说这个不好、那个行，自己又没解决方案。 确实，以前javaeye上有篇文章说的就是别老骂别人的代码烂，说的很在理。在你没完全理解别人设计的思路之前千万不要妄下结论。别人这么设计是有他的道理的，只是有些原因你还不能理解。你在没有完全理解前就说他过度设计只能说你学的还不够。再过2年你就不会这么说了。 确却。。我刚刚毕业的时候 老觉得别人设计的这个不行那个不行，自已设计出来的才是最好的。现在我懂了。不懂别人价值的人，自已才是最没价值的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 |
| 返回顶楼 | |
