|
锁定老帖子 主题：“过度设计”之真实例子
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-30
lpn520 写道 JavaLanguageFun 写道 哎，，LZ 估计刚毕业吧 。这样的架构是很常见的，专为了各种的小系统而设计的 。也能在一定情况下 适应中等系统，不要抱怨说这个架构多麻烦 ，你应该多想想这个架构带来了什么好处 。学的时思想，写代码谁他妈不会写啊！
不好意思，我可能不是你想的那种人，呵呵，思想谁都在看，学JAVA学的是什么呢，还不就是思想，有学算法吗，没有，有学数据结构吗，没有， 只有那一开始的23种模式，再加上无敌的SSH，然后写个HelloWorld建8个类， 到头来却只发现，原来自己做的只不过是 添加删除修改 而已 顶！其实，想一想，为什么PHP中有那么多的开源的系统，JAVA中却没有呢？ 对于小的系统来说，越简单越好！ |
| 返回顶楼 | |
|
发表时间：2010-09-30
teclogid 写道 楼主，首先我要说你连最基本的事务边界可能都不清楚。Service层都没有，按你思路做出的系统，绝对存在数据的不一致性。
为什么要用接口？ 这方面的好处，我就不说了，自己看书去。 Ext为什么要封装？ 这样可以统一界面，如果你每个人都按自己一套创建一个panel，当需要在panel上都加一个按钮什么的，你需要改多少个jsp？人家只要改一个包装的js。任何项目都会用Ext.extend来封装自己的项目组件。 为什么js要提出到单独文件？ 1.、编辑器友好，你在jsp里能代码提示吗，能校验吗？ 2，方便压缩，js和html合并从来都不是什么问题，弄个ant任务就行了。 分的多不是问题，关键是分割都是必要的，按你的思路，弄一个jsp就写一个系统得了，来回请求这个jsp，用标志位判断执行哪一段，那岂不是超级简单了？这样你就爽了？ 难道从“北极”走到“南极”吗？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
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 这个真的很正常... 这个结构确实很正常，我们公司的分层比你的还多两层。一个系统分几层也要考虑到业务和系统的要求，不能一概而论 |
| 返回顶楼 | |
|
发表时间：2010-09-30
jasph77 写道 有时候有弄明白自己到底想要什么？
为什么要这么写？ 不要为了action而action，为了service而service J2EE很多时候告诉企业开发，要这样做、可以这样做。 而很多人没去考虑 为什么这样做，这样做对自己有什么好处。 同意，不论是设计的时候，还是编码的时候都要问一下自己为什么，那样才符合实际的情况 |
| 返回顶楼 | |
|
发表时间：2010-09-30
jasph77 写道 系统架构原则很简单：
1、sql语句只能出现在DAO里面 （到处sql太乱） 2、DAO尽量简单，不要有太多的逻辑判断 （为了能更好的复用性） 3、Action只做跳转、json xml生成，无业务逻辑判断 （Action里有事务，不好控制） 4、service尽量做到有完整的业务逻辑功能，并进行事务控制。 （业务逻辑上的通用性，如：增加用户，我可以form表单提交、也可以用websevice调用，通过ejb访问） 系统架构的设计是以抽象的层次分层的 |
| 返回顶楼 | |
|
发表时间：2010-09-30
最后修改：2010-09-30
不懂路过。。。java是什么？
|
| 返回顶楼 | |
|
发表时间：2010-09-30
t42dw 写道 lz有没有想过，有一天你的业务逻辑变了你需要改动多少代码，有一天你不用spring MVC了你需要改动多少，有一天你所用的数据库变了或者不用ibatis你需要改动多少代码？
当然我说的这些可能以后都不会发生，但没办法我们不是神不知道以后会发生什么只能提前预防。 当然我们也可以不考虑这些可能不会发生的事，不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂 控制，业务，数据操作分开还是很有道理的 就像房子没有30年前的。你做这么多，就能应对变化了？ |
| 返回顶楼 | |
|
发表时间：2010-09-30
lhlpyl 写道 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 这样的设计中小型项目应该不会有什么问题啊 ！ 拜托，这已经不算复杂了。这样的设计，其实还不到位。 楼主是不是做惯了直接print的helloword，学着点吧。 至于说架构的缺陷，其实都是站着说话不腰疼。有不完善的架构，但没有全错的架构。任何一个系统的发展都像一个人的成长的，是有背景的，也是有过程的。拿起来就评论好不好是不地道的。 |
| 返回顶楼 | |
|
发表时间：2010-09-30
night_stalker 写道 嗯 …… 这种东西到处都是，更要命的是一旦业务变动，每层都要改一遍，老费劲了。
有人就是以为写得越多越“灵活”，把复制粘贴当成“重用”，观念以资历增长而根深蒂固化，没办法的。 把复制粘贴当成“重用”,用面向对象的语言写面向过程的代码 |
| 返回顶楼 | |
|
发表时间：2010-09-30
初级贴，不想发言，楼主去吧过度设计的概念搞清楚再说
|
| 返回顶楼 | |
