抛弃框架，走自己的路（一个纯粹JAVA的开发构思）

Question

本帖最后由 fxyfxy 于 2010-03-01 16:29:59 编辑

Answer 1

在天朝，用框架。

4.servelet担当控制，没有任何的配置，修改非常方便，只要修改servelet里if语句，想跳那跳那
===
部署后，客户要修改一个跳转。。修改xml不用重启，而servlet。。
如ls所说

再复杂下去，就会发现越来越多的问题。比如负责根据需求创建对应对象实例的工厂，在实现类很多的情况下，也会渐渐变的臃肿不堪。比如很多地方需要事务、日志、错误调试、性能调优等需求，如果采用硬编码的方式或是辅以设计模式，其耦合仍旧比较严重，要么破坏类的单一职责，要么就因为过多的上下继承关系而变的更加复杂和不灵活。到时候如果想要保持良好的结构和扩展性，更要花大量时间设计和编码。

Answer 2

框架的另一个好处是他的一些规范和一些设计思想，就像use和pci接口一样，使得协作双方都遵循、了解这一规范而省去了很多麻烦，否则，电脑上会多出N多转接器，项目研发中的新进人员每个都要去了解当前项目从下到上的结构设计。
这个影响甚至影响到我们在完全脱离框架，使用servlet/bean/jsp/jdbc时的设计思想。

Answer 3

这里只是我个人的愚见，不能代表什么。你说的规范我就不敢苟同了，你能保证明天不会再出个XX框架？你的规范还是规范么？如果你跟着SUN走用EJB那我不反对，毕竟那不会在短期内失效 。

Answer 4

强烈建议那些从来不写继承想通过框架搞简单的朋友去使用PHP，那是才你想要的简单

Answer 5

啥?个人愚见在这里开贴大说一通，原来不是给人反驳的呀？枉我打了那么多行字，累死了。
1.楼主可以仔细看看自己在此帖中叙述的分层设计部分，其中的一些设计其实已经受到了ssh框架的影响，只是楼主没感觉到而已。这能说框架没有规范？他的流行已经让这些规范深入人心，而这些规范的合理也正是他流行的原因之一。
2.新框架的出现肯定是为了解决新的问题而来的，当然会带来新的规范，和适应新的需求。就像struts2和webwork代替struts1（前两者弥补了后者的很多缺陷），hibernate和iBatis互补一样（同为类似需求的解决方案，但各有优点，各有不同）。
3.ejb适用于大型分布式应用，肯定不适合中小型网站。

Answer 6

个人理解框架用处：
1、解耦
2、统一代码
3、复用，简化开发
4、将精力更关注于业务逻辑不使用fw肯定没问题，
但是从软件工程上讲，会加大很多开发成本。
如果有一个好的、使用熟练的fw，成本方面会压缩很多。现在的问题是软件开发行业工作内容划分不明晰，
很多应该独立出来的应该要框架人员来做的东西，
下放到了更应该关注业务逻辑的普通PG身上，
而很多普通PG都是“见树不见林”的，
不可能关注到负责模块之外的共通化，
所以导致了fw的混乱，也直接出现了"fw无用论"的问题。finally:
fw不是项目最重要的，
业务才是重头戏good luck

Answer 7

让我们抛弃java 抛弃c++ 抛弃 c 抛弃汇编  回到二进制吧

Answer 8

那是理想/完美，我也觉得不现实，
只要在实际项目上能尽量做到就阿弥陀佛了。也和使用者的使用经验／项目开发经验积累量有关。good luck

Answer 9

看了很多框架，最后还是觉得自己写的框架最好用，因为别人的框架你都无法掌握每一个细节，而你自己写的肯定代码不会太多，都是精简的，这样的框架最合适最适用。
虽然我不是做Java的，但还是推荐大家看看我的框架PDF.NET ，思路都是一样的： http://www.pwmis.com/sqlmap
也可以下载框架测试例子：http://download.csdn.net/source/2052993

Answer 10

可是很多做框架的，都是开源，赚的也是对企业进行评估，外包开发等。若只用Spring是免费，做Spring的也没收到钱，但使用对Spring优化过的Tomcat等的时候就要收钱买了。

Answer 11

参考了iBatis.net？呵呵。很象呀。

Answer 12

比iBatis.net 要简单很多，曾经做过一个 iBatis.net 项目，手工写那些映射代码，实体类写到吐血，发誓再也不用这个框架了，于是干脆自己写一个，还配套相关的支持工具，代码生成器。
欢迎大家下载使用阿！ 

Answer 13

当你的页面量拥有 400 个时，如果你全部使用 Servlet，那么 web.xml 中的 Servlet 配置将会是灾难性的！当你的数据表膨胀到 100 张时（100 张表的应用对于 j2ee 来说已经算是很小的了），你会发觉你的这种分层将会出现很大的问题。正如你所说的 DAO 拥有一个 DAO 的类，问一下，如果关联查询涉及多张表，你的 DAO 操作写在什么地方去？如果可以的话，请贴出 DBConnection 和 SQLbase 的代码，我们可以参考一下设计得是否合理。

Answer 14

看了最近楼主唱衰框架的帖子，虽然框架不是万能的，但是如果能在使用时，能领略到其中的设计思想，那我们才是真正学到了东西。就楼主所提到的那些东西，可能在第一次开发时会很方便，但是项目并不是一次性的，以后还需要调优、更改等等。看了一下你说的那些东西，也只能实现一些诸如增、删、改、查、分页等没啥技术含量的开发工作。对于一个应用系统，除了基本的 CRUD 之外，还有就是对权限进行控制，哪类人在这个系统上可以做什么，哪类人不允许做什么等等。作为一个应用系统，统计和分析功能是必需的，楼主所提的东西中也没有涉及相关的部分。

Answer 15

不是说不需要改 也不是说不要灵活 不要自由 可那些东西要拿什么换? 大量的编写不能重用的代码? 
你不觉得用if else比用配置文件更恶心么从头到尾根本看不明白LZ在说些什么
第三部：用servelet取代Struts。Struts给我们什么好处？也就是把跳转弄成了配置文件而已，但写配置文件你头不大么？而且Struts得传参时你郁闷么？还是URL直接传参来的靠谱吧。 
这就是STRUTS的好处?
初衷是什么?
http://topic.csdn.net/u/20100222/22/8c1317ac-0d6c-4a9c-a8f0-bd0b7e4bc16f.html
这个贴的LZ他有他的想法 甚至他都把这个实践出了 他讨厌的东西 他多少能列举出理由 不过他跟LZ一样 不明白自己为什么用框架

Answer 16

呵呵，小结一下。
1.没做过大项目，没见过过千的类和几百个页面带来的对设计的冲击和压力。
2.太在意框架，框架只是个额外的选择而已。
建议用ssh和servlet/javabean/jsp好好做几个上点规模的项目后，再来评论下，更有意义。呵呵。

Answer 17

框架是前人总结出来的东西，每个框架的产生必有其优势之处，也有其不成熟的地方，至少在大型项目的开发中，框架的运用还是非常重要的。如果只是servlet+jdbc就能搞定一切的话，那我们还学框架干啥？

Answer 18

jdbc比起hbn太不方便了， 你这样封装过去， 跟我用一个通用的basedao差太远效率了。
struts那里我倒想学lz那样试试……

Answer 19

再借机推销一下ibatis，
感觉现在很多项目都是“赶时髦”而上的hibernate。ibatis的半自动步枪...错了，半自动orm才是高效率开发和高效率执行的...一个选择。good luck

Answer 20

现在开发的项目，什么框架都不用，就是jdbc

Answer 21

我对这个倒是比较感兴趣 ibatis 在跟struts2一起学不过ORM效率不高不一定是因为SQL语句的事情 如果我们非常非常熟悉他 并且任何操作都选择最恰当的方式去完成 我想效率不会太悲剧的 至少没传说中的悲剧

Answer 22

哎，大哥又来了，好歹你也先看看我的主贴吧，写的很辛苦的你瞅都不瞅一眼啊 。。
1.我Servlet只用了一两个，没有什么web.xml配置
2.什么叫“关系”数据库啊？关系数据库是有能力解决大半业务逻辑的，SQL很强大的，为什么老有人把数据关系拿到后台代码里呢？最简单的就是数据视图，你有1万张表我都能写个视图获得我想要的数据
3.除了增、删、改、查、分页你还常用那些啊？数据库，为什么叫“数据”库不叫其它什么库啊？就是它对数据的处理能力极强。数据库是很伟大的，悲剧在你不知道它的伟大。
4.权限问题说了放在fiter里面啊，最后写权限是一种技巧，你要是先写权限测试的时候光填密码就累死你了，放在过滤器里可以测试完了再加上FITER多好。还有，这也是过滤器存在的意义之一。
5.逻辑放在页面bean里，你有多复杂你写多点呗，说实话除了操作数据库中间件真不知道还在做什么，安全问题被过滤器屏蔽了啊。
也许我的理解狭隘了吧，不过我感觉中小型运用足够了。

Answer 23

Mark                                      `

Answer 24

我想用框架的人还是要像LZ这样对jsp设计基础熟悉的！

Answer 25

a.我和楼主起始的时候一样，喜欢自己设计符合自己的结构，但是在几个项目下来之后，其灵活性和团队合作太差了，于是回到了ssh
b.说真的，要想通吃一类项目的话，设计出这样一个结构，花的时间可以顶上好几个项目了，而且需要大家赞同，自己一个人用那无所谓的了。

Answer 26

   有个人见解！
   Good！

Answer 27

...其实lz可能刚做java应用不久 估计不会超过3年这个现在的SSH是历史背景的实施上 讨论应用架构的事情在5年前都已经是疯狂状态了因为7年前struts刚刚流行之前，存在着一个经典框架 现在叫啥 exliber 记不清了(现在这个框架已经进入坟墓了吧,好像被肢解成多个小项目了。)。。当时是apache的一个顶级项目使用方式就更LZ的类似
不过封装稍微复杂点基本使用factory模式+DAO模式的形式初步实现了MVC思想
之后就开始流行struts1 以及webwork  因为他们根据有MVC概念而另一方因为其大量使用factory模式以及“接口注入”方式让一部分人很反感，所以出现Spring为代表了IoC框架  而对于DAO模式有意见的某打拿开始研究ORM,也就是现在成为实施上标准的“hibernate”（还有轻量级的ibitis）而整体框架其实很早就出过一本相当著名的书POEAA LZ有兴趣可以研读一下
现在的b/s应用绝大部分无非都是record model 或 table module 或 trasaction script的变种知道 Rudy on Rail么？ 前几年很流行的，其实就是“record model”的经典实现版
还有MS的开发核心 那个所有。net开发必用的“二位表” ，就是table module的核心概念

Answer 28

...接上面的我说的那个apache框架 ：avalon 
现在分裂出 Excalibur  Phoenix Merlin 等子项目其实以前的log4j都深受该框架影响可以看看2004年的新闻
http://news.csdn.net/n/20041201/18569.html
http://avalon.apache.org/closed.html

Answer 29

哎这也说明了框架在时间上的弊端啊，struts1在2001年正式发布的，估计在2004年火的，而现在struts1已经被struts2淘汰了，要知道Struts2并没有继承Struts1的血统，而是继承WebWork的血统，换句话说struts1的活跃寿命只有区区5-6年，这也淘汰的太快了吧，等你把struts2弄透了你发现又出来个struts3了 悲剧啊 

Answer 30

他山之石可以攻玉，我在用.net MVC,看了lz的帖子和回复，也有收获。顶一下。

Answer 31

   如果非要选一个框架的话我宁愿IBatis，起码它给你写sql的权利，要知道数据库才是IT行业运用而不局限于web的命根子，数据库具有强大的业务逻辑能力，没了写SQL的能力你想把项目做复杂那可就难了，代码逻辑还不写死，这也导致java代码逻辑变复杂，因为数据库功能被束缚了不灵活了，业务逻辑自然跑到实现代码里了 关系数据库此关系即为逻辑，任何想完全封装SQL的框架必然做不了大事，就像C语言一样，它是母体。
    话说回来有学哪些框架的时间SQL早学的光瓜烂熟了，这些框架弄来弄去还不就是想省些sql？理论上讲一个链接和一行sql就可以获得数据了，我个人感觉SQL操作数据库已经非常经典了。
    我有点质疑：为了迎合java的OO思想就一定要把数据库类操作化么？就算出来一个完美的中间件把SQL彻底屏蔽掉了，最终的结果也只是把一行SQL语句变成了一个具有数据库列名的类，仅此而已，也就说换了一种写法，但是问题来了，要知道sql本身是有逻辑功能的现在没了，那么最终结局是：数据逻辑全部跑到语言层了，我可不认为JAVA的逻辑能力比SQL精简，你可能要写N多if…else来完成数据库逻辑。
    还有一种完美结局：诞生一个OO的数据库，但是那要等到猴年马月？

Answer 32

怎么说法 在以前讨论中 我翻整得出结论是项目中尽量少引入不必要的东西，但不排斥引入比如你做个10个表的小应用就完全没有必要使用hibernate
如果你的页面根本就没有很多表单流转，那就不需要struts唯一感到伸缩性比较强的是spring因为就算你开发1个表的应用都可以用到spring+dbcp的用法
至于你的构架要我去弄 直接 就一个DAO模式可以了MVC用不用主要看你到底有多少页面,页面复杂度而已....还有MVC框架其实都是1通百通的...无非就是 servlet-dispacher action接口(DI式的) 页面流转配置 validate配置 这些东西 无论struts1 2 还是 webwork 还是其他用Java实现MVC的web架构都类似的...
只要记住这种模式就行了...要用的时候熟悉一下...然后就用...spring么也就不过是 type 2型注入(IoC概念) ... 在我看来只不过是用配置文件进行BEAN勾连,并提供应用初始化时load的东西而已...这种东西自己都可以写出来..只不过优化度没有他们高...hibernate么我觉得太复杂了..反正个人觉得，为了没有数据缓存的项目，去用这种东西。。只能一声叹息。。艾~~ 有其在那种表多但是都是curd操作的项目中，那耗费的系统资源可能比带来的益处厉害很多毕竟不是所有人都能真正理解hibernate内部各种神秘莫测的机制的弄到最后还要高级程序员去封装，制定规范，限制操作等等等。

Answer 33

比较同意spring+ibatis 是不错的选择 spring自己也有MVC框架 叫 spring mvc 哈哈 不知道现在还有没有。。不过如果你在条约思维一下，其实你完全可以用grail+java的来提高一般web应用的开发效率
所以基于技术去研究应用架构是不对的。。其实应该基于模式来讨论这样你的知识才能积累下来
技术日薪月异的太快除非一种技术已经成为真正意义上的垄断机制比如现在的unix/linux操作系统OO数据库是有的 只不过不完善而已 

Answer 34

本来我也想用一个DAO的后来想想不对，因为实现的时候每张表的功能不一样，而我实现时是继承了上面的SQLbase它包含了N多操作，如果写在一个DAO里就得全部实现，那会带来运用时的安全问题，因为不该有的操作也被实现了，这是和实际矛盾的，所以还是分开好，各自的表实现各自的功能多好，而且弄的大点工程的话也好彼此分离不至于最后写个过大的类看起来累人，弄个大肚子多不好啊，哈哈 

Answer 35

完全同意，我们在使用.net MVC 框架，借鉴的看java的框架，感觉道理上一致的，只是具体实施上有些许区别。在.net世界里，对应的HHibernate也是同样的问题，所以很多人开始使用Flent NHibernate，等一些封装好的工具。

Answer 36

1 楼主是参照了框架的思想，自己设计的东西融入了框架的思想，只不过是自己实现的而已，自己便于维护。但恰恰是这一点成为以后的灾难，后期维护需要维护框架，对应一个大的项目而言，越维护越困难，最后可能不得不放弃，那将是灾难性的。
2 有关楼主的“用if 想跳哪里跳哪里”，偶不敢苟同，那不有回到goto语言了吗。

Answer 37

哦，和楼主一样，自己写框架，即简单又明了，和我写的.net框架差不多一样。目的只有一个，快速开发无BUG。