本文共 12905 字，大约阅读时间需要 43 分钟。
最近看了一篇贴子，链接地址:
楼主的观点是抛弃框架，走自己的路，写自己的代码，写自己的思想
其实我本人是不同意楼主的观点的，框架是应运而生的，有这么大的使用范围，必有其存在的道理，但是今天要说的并不是关于框架的，而是关于自己的学习方式或是工作方式，都在用框架，我也用框架，可为什么要用框架？用框架能带来什么好处？不用框架能不能实现？能不能写一个自己的框架？在这之前我真的是很少有去想这些问题，只知道一味的使用，唉，看了人家的贴子才知道自己以前真的是太懒了，从没有主动去思考！框架本来就是开源的，它们是怎么实现的？自己为什么不去看看呢？
下面是贴子的原文摘录以及一些有思想的前辈的回复，之所以贴出来，真的是使我感触良多：
原作者观点：
俗话说“不要在一棵树上吊死，到周围的树上试试”，我们在层出不穷的框架上滴血流汗，被框架框的严严实实。
在这里有必要提倡写自己的代码写自己的思想，别人的东西虽好但那是有环境的不是所有情况下都完美的，我们可能背离了计算机语言的初衷——实现自己的想法。这里我和大家简单讨论下tomcat下开发的一种自己想出来的模式，用简单的方法实现MVC。 第一步：用静态html+css+div+js开发静态页面，反复修改满意后继续下一步（此可由美工实现） 第二步：封装自己的持久化工具。运用DAO模式+工程模式对数据库进行封装，实现持久化，再次强调对象的持久化其实就是把对象属性存到数据库，所谓持久化方法就是封装JDBC增删改查等基本功能的类，调用时传入一个带属性的类，然后封装类取得传入类的属性并调用自己的方法把数据存入数据库，这就实现了传入类的持久化。 定义表Vo包： Tab1Vo（属性和表列名对应） Tab2Vo Tab…Vo DBConnection.class（DB连接类，以下省略.class） 调用DBConnection | SQLbase（增删改查…类，参数决定SQL访问表） | ———————————- | DAO定义包： Tab1Dao（对应DB表） Tab2Dao Table…Dao | | | | | Dao实现 Tab1DaoIm(Tab1Vo) Tab2DaoIm(Tab2Vo) Tab…DaoIm(Tab…Vo) <—- 继承SQLbase | | | ——————————————————— | 工厂包： factory（实例化工厂） 在调用时只用到 定义表Vo包 和 工厂包，new一个表对应Vo类，调用factory实例化表对应DAO对象，因为实例化对象继承了SQLbase所以它具有SQLbase定义过的任何增删改查…操作，一旦到运用时你会发现，我们只是new了一个Vo类然后用工厂实例化一个对象并传入Vo实现所以数据库操作，这就是所谓对象的实例化。 现在来分析封装代码量， 1.定义表Vo：其实就是以表名为属性建立一个简单类并生成getter和setter，没了。 2.DBConnection：一成不变的JDBC连接数据库，核心不过10行代码。 3.SQLbase：这个类可能要复杂点，现所有需要的数据库操作，一般就增删改查…（分页在此通过SQL决定），你会发现由于它是从DBConnection返回DB连接的所以具体DB被分离，这个类以后可以拿到任何地方去操作DB，只要修改一下DBConnection。 4.Dao实现：由于SQLbase封装了N多操作，但你的某张表并不需要，这时可以在这里裁剪，由于继承了SQLbase，只要根据Vo传参调用SQLbase方法就实现了，代码小于30行。 5.factory：就是简单返回Dao实例，一个调用没了，代码很少。 在DB中可以用统一的表命名法比如Table1，Table2，Table3，Table……并在注释中体现具体对应，这样你的封装以后可以在任何类似场合用，根据你SQLbase功能的强大，你的封装不比Hibernate差，关键是这是你写的你对它了如指掌。 第三部：用servelet取代Struts。Struts给我们什么好处？也就是把跳转弄成了配置文件而已，但写配置文件你头不大么？而且Struts得传参时你郁闷么？还是URL直接传参来的靠谱吧。 1.创建页面控制servelet： servelet（用于跳转和控制的servelet） | | 获取URL参数id…并过滤(这里id…指URL传的多个参数)，如非法跳转错误jsp页面 | | if（id1…）{ 调用页面bean1(页面bean下面会讲)获得数据，跳转到相应jsp } | | if（id2…）{ 调用页面bean2获得数据，跳转到相应jsp } | | if（id3…）{ 调用页面bean3获得数据，跳转到相应jsp } | . . . else{ 跳转到错误jsp页面 } 第四步：实现页面Bean 2.实现“页面bean”，众所周知JAVA是面向对象的，这里的“页面bean”对象就是JSP页面，页面bean里提供了对应jsp页面所需所有动态数据，包括下页id参数、导航路径等一切动态的数据，这样的好处是你在第一步建立静态网页时只要建立几个模板，然后传参调用，根据参数显示不同内容，但是你调用的始终是一个JSP不同的是里面的内容，这样就重用了JSP。 所有的数据库调用和业务逻辑都是在页面Bean里实现的，页面Bean里有N多属性，对应了JSP页面各个动态数据，在页面Bean中可以调用其他功能Bean。举例： PageBean1 | ———————————————————————————————— …… | | | | | | 属性： 当前页面导航 页面内容List 日期 下一页id 上一页id 作者 …… 3.实现页面bean工厂。PageBeanFactory可以实例化并返回所有页面bean。 现在我们来运用：在显示页面只需导入页面bean工厂包 和 页面bean包，这和持久化封装其实是一个道理，new一个页面Bean调用时用工厂根据参数实例化当前页面Bean，然后用<%=bean.属性 %>的方式来显示页面内容。如果要修改显示内容只需要修改页面Bean，显示层不变，任何数据来源、逻辑都在页面Bean里解决，完全和JSP显示层解耦。 第五步：建立过滤器。所有安全问题，权限问题，编码问题，一律放在过滤器里过滤，不合法的一律跳转错误页面。每当用户进入把过滤IP的专用Bean实例引用传给其Sessen，一旦用户非法操作达一定数量拒绝其访问。 第六步：配置服务器安全，在web配置中配置404、505、I\O异常等一律跳转错误页并设置错误页3秒后返回主页。杀掉地址栏前面的小猫，建立自己的favicon.ico并配置WEB文件，配置跳转servelet后缀名，影藏后台实现语言。 总结：到这里你会发现： 1.你的代码和BD或其它数据来源完全解耦 2.和显示层JSP完全解耦 3.你的持久化可以在任何场合(看你封装能力)复用 4.servelet担当控制，没有任何的配置，修改非常方便，只要修改servelet里if语句，想跳那跳那。 这里只是我个人的心得，“我写我的代码，我写我的思想”，让我们抛弃框架的束缚吧，没有框架你一样可以做到，我相信你一定有更好的实现方法。
下面是回复：
楼主的这一贴我又来唠叨了，呵呵。
我觉得设计应当遵循当前需求，而不是尝试着设计个什么而妄想着他能适应很多种情况的需求。只要稍微复杂点的小网站，他们的底层都可以表现出比较大的需求差异。 楼主所讲的那几层该如何设计、架构，确实能解决很多简单网站的需求，但再复杂下去，就会发现越来越多的问题。比如负责根据需求创建对应对象实例的工厂，在实现类很多的情况下，也会渐渐变的臃肿不堪。比如很多地方需要事务、日志、错误调试、性能调优等需求，如果采用硬编码的方式或是辅以设计模式，其耦合仍旧比较严重，要么破坏类的单一职责，要么就因为过多的上下继承关系而变的更加复杂和不灵活。到时候如果想要保持良好的结构和扩展性，更要花大量时间设计和编码。 框架算是为了解决开发中一些很常见的需求而生，或是为了解决一些很常见的问题而生。他同样不是处处都适合的。 框架并没有强求任何人一定要去使用他，正如论坛里某位前辈在博客里说的那样：只是多了几个选择而已。
1.楼主可以仔细看看自己在此帖中叙述的分层设计部分，其中的一些设计其实已经受到了ssh框架的影响，只是楼主没感觉到而已。这能说框架没有规范？他的流行已经让这些规范深入人心，而这些规范的合理也正是他流行的原因之一。
2.新框架的出现肯定是为了解决新的问题而来的，当然会带来新的规范，和适应新的需求。就像struts2和webwork代替struts1（前两者弥补了后者的很多缺陷），hibernate和iBatis互补一样（同为类似需求的解决方案，但各有优点，各有不同）。 3.ejb适用于大型分布式应用，肯定不适合中小型网站。
个人理解框架用处：
1、解耦 2、统一代码 3、复用，简化开发 4、将精力更关注于业务逻辑 不使用fw肯定没问题， 但是从软件工程上讲，会加大很多开发成本。 如果有一个好的、使用熟练的fw，成本方面会压缩很多。 现在的问题是软件开发行业工作内容划分不明晰， 很多应该独立出来的应该要框架人员来做的东西， 下放到了更应该关注业务逻辑的普通PG身上， 而很多普通PG都是“见树不见林”的， 不可能关注到负责模块之外的共通化， 所以导致了fw的混乱，也直接出现了"fw无用论"的问题。 finally: fw不是项目最重要的， 业务才是重头戏让我们抛弃java 抛弃c++ 抛弃 c 抛弃汇编 回到二进制吧
楼主的想法很好
但是框架有框架的好处 一个框架的流行 是经过了无数次的验证 不管是在架构还是性能方面都很好 如果每个公司都要自己封装的框架 那么 不是每个公司都有那么多人力物力来支持的 何况对后期的维护 都很麻烦 新员工进来还得学习新框架 但是如果是楼主那样的设计 只适合小型项目 如果是大型项目 楼主那样的设计就不行了
当你的页面量拥有 400 个时，如果你全部使用 Servlet，那么 web.xml 中的 Servlet 配置将会是灾难性的！
当你的数据表膨胀到 100 张时（100 张表的应用对于 j2ee 来说已经算是很小的了），你会发觉你的这种分层将会出现很大的问题。 正如你所说的 DAO 拥有一个 DAO 的类，问一下，如果关联查询涉及多张表，你的 DAO 操作写在什么地方去？ 如果可以的话，请贴出 DBConnection 和 SQLbase 的代码，我们可以参考一下设计得是否合理。如果能在数百个页面，数百张数据表的应用中采用您所述思想的话，那么你的思想就是可行的，否则一切都是空谈。
看了最近楼主唱衰框架的帖子，虽然框架不是万能的，但是如果能在使用时，能领略到其中的设计思想，那我们才是真正学到了东西。 就楼主所提到的那些东西，可能在第一次开发时会很方便，但是项目并不是一次性的，以后还需要调优、更改等等。 看了一下你说的那些东西，也只能实现一些诸如增、删、改、查、分页等没啥技术含量的开发工作。 对于一个应用系统，除了基本的 CRUD 之外，还有就是对权限进行控制，哪类人在这个系统上可以做什么，哪类人不允许做什么等等。 作为一个应用系统，统计和分析功能是必需的，楼主所提的东西中也没有涉及相关的部分。
我说几句哈
1).并不是所有的开发都得用框架,完全根据实际情况来决定,比如一个小型网站,就没必要用吧. 2).使用框架可以实现快速开发,这是不用质疑的.框架带给我们的不仅仅是快速开发,还有他的设计思想和自己的独到之处. 3).程序开发应当尽量避免硬编码,像楼主说的改源码,不如改配置,这种能避免的就尽量避免了
如果非要选一个框架的话我宁愿IBatis，起码它给你写sql的权利，要知道数据库才是IT行业运用而不局限于web的命根子，数据库具有强大的业务逻辑能力，没了写SQL的能力你想把项目做复杂那可就难了，代码逻辑还不写死，这也导致java代码逻辑变复杂，因为数据库功能被束缚了不灵活了，业务逻辑自然跑到实现代码里了 。。。关系数据库此关系即为逻辑，任何想完全封装SQL的框架必然做不了大事，就像C语言一样，它是母体。
话说回来有学哪些框架的时间SQL早学的光瓜烂熟了，这些框架弄来弄去还不就是想省些sql？理论上讲一个链接和一行sql就可以获得数据了，我个人感觉SQL操作数据库已经非常经典了。 我有点质疑：为了迎合java的OO思想就一定要把数据库类操作化么？就算出来一个完美的中间件把SQL彻底屏蔽掉了，最终的结果也只是把一行SQL语句变成了一个具有数据库列名的类，仅此而已，也就说换了一种写法，但是问题来了，要知道sql本身是有逻辑功能的现在没了，那么最终结局是：数据逻辑全部跑到语言层了，我可不认为JAVA的逻辑能力比SQL精简，你可能要写N多if…else来完成数据库逻辑。 还有一种完美结局：诞生一个OO的数据库，但是那要等到猴年马月？
哎。。。这也说明了框架在时间上的弊端啊，struts1在2001年正式发布的，估计在2004年火的，而现在struts1已经被struts2淘汰了，要知道Struts2并没有继承Struts1的血统，而是继承WebWork的血统，换句话说struts1的活跃寿命只有区区5-6年，这也淘汰的太快了吧，等你把struts2弄透了你发现又出来个struts3了 。。。悲剧啊 。。。
怎么说法 。。。在以前讨论中 我翻整得出结论。。。是项目中尽量少引入不必要的东西，但不排斥引入。。。 比如你做个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内部各种神秘莫测的机制的。。。弄到最后还要高级程序员去封装，制定规范，限制操作等等等。。。。LZ的意思大概是不要为了框架而框架.任何一种框架,其实只是为了更加有序的,规范的组织我们的开发流程,并且提高我们系统的可扩展性和稳定性,以及开发的效率.所以当我们熟悉在一种框架下开发时,就容易陷入思维定势. 在我们使用框架的同时，应该做到理解其中的原理,并且根据实际的情况,做出自己的调整.
不知道楼主所设计的代码中是如何处理事务的。 事务不管在 J2SE 环境中，还是 J2EE 环境中都是相当复杂的。开源 J2EE 应用服务器与商业 J2EE 应用服务器之间最大区别也就是各自对于事务系统的设计，当然了开源始终没办法跟商业技术相比的。 事务有不同的隔离级别和传播属性，楼主在编写代码或者自行实现一个事务处理时应考虑这些。 另外，楼主在代码中使用下面这些代码，足以看出楼主目前仅停留在面向过程的程序设计之中！没有充分从可扩展、可维护的状态上去考虑。
if （id1…）{ 调用页面bean1(页面bean下面会讲)获得数据，跳转到相应jsp } | | if （id2…）{ 调用页面bean2获得数据，跳转到相应jsp } | | if （id3…）{ 调用页面bean3获得数据，跳转到相应jsp } | . . . else { 跳转到错误jsp页面 }
..... lz 只是菜鸟看法...
不写java 但是也对框架交互过。 框架是什么？ 就是些经验，一套固定的模式，这套模式可以解决很多问题。用wow 打副本打过没有？ 一开始大家都不知道怎么打，上去就灭掉。 后来有些高手先过了，就总结出经验， 比如 T 在最前面 奶妈 dps 跟后面。 队长一喊就集合。 然后框架就出来了。 副本越来越多，框架越来越复杂。 到了后面，光是这些经验就有4 50条,大家受不了了。 又开始返回老路，开始野团作战。又开始走lz的老路。 后来发现有出了wow 11条。 嗯不错。很容易就会了。但是于是新框架又出现了。世界就是这样反复着。 所以关键要明白框架的原理和实际。只是用框架， 你永远走不出这个圈。 这是个轮回。第一点, 在servlet中充斥了N多的if...else的时候, 代码会是什么样子呢? 第二点. 楼主谈到struts的取值机制不好, 不如URL传参. 这个是严重不同意的, URL是有字符数限制的, 另外一方面, URL传参可能会涉及一些编码和安全问题, 这一切是因为当时的URL传参更多是设计给GET请求的, 这方面可以看看HTTP规范中关于GET. 哪怕使用POST方式, 隐含的发送数据, struts的参数获取机制都是值得称赞的, 无论是1.x还是2.x, 都对集合, 映射, 自定义类型等有很好的处理方式, 试想, 如果一个稍微复杂的系统, 比如我们这边, 经常一个实体有上百个属性, request.getParameter会累死的, 要想封装, 那就又走到了struts的路子里了....
我又来啦。。哈哈
LZ没关系不用太在意“框架派”的板砖。 就一个项目本身而言，只在于能不能完成，能不能达到用户目标。更用不用框架无关。 只是对个人么，学会SSH么找工作机会更大更大一点。 所有框架都有局限性与复杂性，所以没必要太那个啥了。。。 学会通用的概念，需要用时才用比较好。 其实关于“框架派”说你那个控制器servlet都是"if else if else"不好。你 就说我以后用groovy 或者 服务端javascript来实现就好啦。。。还有啥OO思路还是过程思路，其实也啥关系，页面流本来就是过程化的。。
画条线吧，
比如： 10人月以内的项目，不要用复杂的框架。 10人月以上，使用成熟、并且充分封装过的框架。 其实还是那句话， 存在既是有道理， 小项目使用短平快的战术，框架从某个角度讲的确是加重了开发负担， 就像打仗1v1，穿着重铠拿着重兵器， 有时可能会妨碍肢体灵活，会适得其反。 但是一旦变成中大项目， 框架的好处在这个时候就能体现出来了。 整齐化一的军容军纪，能使战斗力大大提升。 尺有所短，寸有所长就是这个道理吧好的程序无非就是不断地重构，形成框架
你自己花了NNN多时间搞出来的东西，或许别人早有团队写出了类似功能的框架，功能还比你的多 那么，与其自己花那么多时间写，最后还要改bug，加需求，教会其他人，何不直接用别人开源现成的东西呢，简单实用。再说，你敢保证公司新招的人可以立刻上手这个框架吗，还是用大路一点的框架比较好？ 当然，大牛团队全部自己写的例外。 我觉得，能用开源的，用开源的得了，大部分的公司还是制造型软件企业，没必要整到复杂的路上 个人意见，欢迎拍砖！！
最早的开发都是用Jsp + javabean的方式，一个项目搞好了，几年都不出问题，后来用了框架，这问题那问题就开始多了（当然有很多是认为因素）
现在基于流行框架我们自己又搞了一套，确实在一定程度上使程序员的工作更加标准化，让程序员把更多的精力放在业务逻辑上。 至于是否使用框架，我觉得完全没有争论的必要，从我多年的开发管理经验来看，完全取决于实际项目。其实真正遇到比较急的任务并且又不大的情况下，最简单的JSP + JavaBean足够了，而对于相对比较大型的项目，多人合作的时候，框架的优越性就能慢慢体现出来了。所以一点要看实际情况来取舍的。
自己写框架的代价是相当巨大的，一个框架要达到，真正“设计框架的初衷”，是要经历相当长的时间的，我就一直用自己写的框架，能解决很多第三方框架所不能解决的问题，但是我当初是从NET刚出来时，逐渐积累出来的，也花了大量业余时间去实践，改进，回过着来看看，真正最合适的框架，最好还是基于一些比较稳固的流行技术来写，而不是完全重写，只可惜，我当初积累框架的时候，NET也刚出来没多久，没多少值得作为基础的东西。所以最后自己写也挺过来了，如果现在让我给点什么建议的话，我想简单的这么说：从数据访问＋服务提供＋数据传输＋UI从这四个方面入手，逐步积累，借鉴或是在成熟工具生成的代码的基础上写自己的框架，可能比较现现实，我最近在研究几个新的技术，要基于这几个技术，写一个框架，还没出成果，暂时不提。不过框架的初衷，最终还是要解决问题的，所以写框架一定要有很多实践经验，你每设计一个结构，每实现一个什么组件或是类，要多想想，他能解决哪方面的问题，这些问题价值大不大，普遍不普遍等等，只要以平心静气，经过一两年的积累，我想信无论从个人能力，还是对编程的理解，还是编程的耐心，以及和同行的沟通能力、现成的积累都会提高不少。
首先我非常理解lz的心情，我们做程序员的总想写出完全自己的代码，这样才有成就感嘛。。
但是我们在程序设计中所要做的最重要的事之一就是避免代码的重复，既然有现成的代码，而且已经相当的完善了，我们为什么不拿着用呢， 写代码还有一件很重要的事就是代码的可重用性，可读性，都用一样的框架不是刚好符合了程序设计的思想吗 我本人还是很赞同使用框架的，框架会使自己的代码更加健壮。。。。当然我更期望有更多的人去开发框架。。哈哈
不要重复的发明轮子。
说实话感觉你的思想并没有什么特别亮点的地方，不过你的SQLbase如果写的很通用灵活的话还可以，但你让VO类去继承这个类，我感觉很不好。 最让我不理解的是，你说“struts也就是把跳转弄成了配置文件而已，但写配置文件你头不大么？” 可以通过通配符来解决配置文件臃肿的问题。 但你自己写的这个类，不知道以后会多臃肿。 1.创建页面控制servelet： servelet（用于跳转和控制的servelet） | | 获取URL参数id…并过滤(这里id…指URL传的多个参数)，如非法跳转错误jsp页面 | | if（id1…）{ 调用页面bean1(页面bean下面会讲)获得数据，跳转到相应jsp } | | if（id2…）{ 调用页面bean2获得数据，跳转到相应jsp } | | if（id3…）{ 调用页面bean3获得数据，跳转到相应jsp } | . . . else{ 跳转到错误jsp页面 }
每当听到SSH都恨得牙痒痒,几乎我所见过用这个东西的项目都是为了用它而用它!
框架只是说有些事情可以这么做,很多事情有这样的共性! 可能跟我所经历的项目特征有关系吧:24*365,全年停机时间不能超过5小时 没从SSH上捞啥好处,倒是查问题费老劲,比较典型的,在WebSphere上可以监控每个servlet的性能状况,结果一看,只有一个:action 哎...
其他有些东西还是觉得楼主有自己的想法挺好。不过等你项目变大之后，你会发觉自己的框架又不够用了。你现在的困惑主要是源于对现有的框架觉得无法精确了解和掌控，而自己的框架可以非常精确掌控。很多人开始的时候都会有这样的感受。框架这个问题，还是要看项目大小，小项目其实不需要用框架，更简单方便。
关于写监听端口程序，和接口技术是没有什么关系的。 接口技术这门课程主要讲的是硬件接口编程方面的内容。
我从1楼欣赏到楼未，我所看到的都是评判框架后期维护的；
首先，我对楼主的做法和思想，非常尊重。 其次，你能引来果子先生的注意，我感到十分羡慕。 本人针对LZ的话题，给出几句话。 以下仅代表本人个人观点。 1、我学习java的目的就是面向对象，而不是面向过程。 2、作为开发人员我们不是为了开发而开发，而是为了生活而开发。 3、LZ的思想并不能再此帖中有具体体现。 4、任何事都要具体问题具体分析着解决，不能什么都是通用的。 5、针对你的框架我想问下，如果我需要使用复合查询多表查询， 我应该把我写好的sql放在哪里，还是说你的框架本身就支持复合查询， 或者级联查询，针对关系型数据库的数据，又该如何处理呢？ 6、还是对果子先生很崇拜的。 7、开发语言只是一种思想，但模式是可以使用在其它方面的。
看怎么理解了，我认为，你可以把ssh看成3种框架，也可以把ssh看成一种集成的框架，强悍的人可以把ssh作为一个底层框架后在与其他的页面框架进行集成，那么最后的成果也称作一个框架，那么我认为最后的框架绝对能受到lz们的青睐，哪个人愿意在一个项目来临是从最底层的权限模块写起？估计没有吧，更多的是集成基础数据模块形成自己框架后，再进行对新业务的开发吧！
有本事你一个jar包都别引用!!!
如果觉得这个轮子不适合你 你也不用自己做轮子 ，改造轮子 这个也是你自己的创新嘛。如果你实在是想自己搞那么 那么多类库 形同一个个的小框架，你也不惜得用。建议你做个编译器 自己开发个 语言 。当然你要显示出来你的实力 ，只用汇编搞定 。
菜鸟发表下个人看法：我敢断定楼主没有理解三层框架的思想原理，及使用了哪些设置模式，原因很简单,不喜欢接受别人的代码 根本没有较深入的看框架源代码，如果学java不看源码不不如学微软的那套web开发
一方面是企业和管理层期望使用成熟框架降低开发升本，从技术上一定程度的保证代码的稳定性和一致性
另一方面是开发人员渴望接触到更底层代码，而不只是写写配置 这本身是一个矛盾体 框架的日趋成熟和壮大，使软件从业人员渐渐向产业工人过渡 框架是大势所趋，就像其他工业产业一样，虽然软件行业不可能形成制造业的流水线，但是趋势如此 对于刚刚入行的软件从业者来说，发展的方向不再是在一个项目中成为一个技术精英，这条路已经越来越窄了，可以考虑以下几个发展方向 1、技术方向：继续钻研技术，不做框架使用者，做框架开发者，或者提供成熟框架咨询 2、业务方向：向业务方向发展，掌握业务知识 3、管理方向：向管理层发展，需要学习管理知识 当然，还有其他一些方向，还望各位补充
着实佩服LZ，因为在这方面的选择下，我屈服了，最终我还是走上了框架这条路，看到LZ的这个帖子，我想谈一下我个人的一些认识，当然有些浅薄。
1. 关于持久层。自从使用ibatis这个框架后，我觉得这个东西很方便。最近我一直在琢磨层次结构中，dao层到底应该完成什么样子的任务。我个人觉得，ibatis的sqlMap文件，就已经完成了dao层需要完成的任务，因为它明确了对象与关系数据库之间的映射关系。所以在持久层，可以通过XML来控制，加之反射，可以通过配置完成对象映射。我还是觉得JDBC来get，set属性配置方法工作强度挺大的。 2. 对于action方面，利用if控制业务去向的方法固然好，但是我们要把每一个方法暴露在地址栏里。其实，我也很喜欢struts2的做法，我们可以通过filter，对每一次访问的路径进行过滤，然后把我们后台的servlet配置到XML文件中，并且把它们在第一次请求中缓存起来，然后针对访问，我们从中获取对应的servlet信息，处理后，返回响应信息。当然我们也可以自己模拟struts这个东西，因为java很好的提供了代理类，这样我们可以将切面的东西运用过来，让proxy对业务处理之前和之后做好控制，servlet完成业务处理。
如今主流JEE系统的开发框架中，通常显示层使用MVC框架，中间业务逻辑层使用spring，持久层采用Hibernate/JPA.这种组成几乎是毫无争议的典型架构体系，但若我们将这三个组成部分完全从我们脑海中清楚，以空杯的心态来看JEE系统的开发，我们就很容易地发现我走弯路了。IE浏览器把form表单中的所有元素以key-value方式传到后台，逻辑处理会把这些元素做相应的修改，然后存到数据库中，主流数据库是以二维表存储方式，二维表的每一条记录其实就是多个key-value。既然数据的起始端和结束端都是key-value，那么为什么我要在中间加入那么多Javabean呢（我这里并没有说不要JavaBean之类的话），如果JavaBean少一些系统开发是不是应该更快一些，维护更方便一些呢？再看看这个典型架构体系，数据通常是这样交互：form-->key-value-->formBean-->entityBean-->DB,第一箭头是IE完成，第二个是MVC框架完成，第三个就是spring处理业务逻辑时完成，第四个是Hibernate/JPA完成。开发人员会经常发现formbean和entityBean很多属性是相同，存储时要做对拷，很明显有悖于复用。而产生entityBean元凶是Hibernate/JPA,它以习惯性的面向对象的思想，以对象持久化封装了一组原子数据（key-value）的存储。其实持久化了东西就是很多属性的集合，即key-value的集合。entityBean是一个类，具有名称，要单纯比一组key-value更加形象。要是给这组key-value也起个名这点优势也没了；再说跨数据库，在现实开发中真正跨数据库的不太多，如果都采用JDBC+标准SQL也同样可以跨数据库；因使用它增加的学习成本，开发成本，维护成本已经覆盖了它的形象优势。
我是想提出一种基于key-value的持久方式，没有学习曲线，大大提高开发效率，降低维护成本。这就是我开发的基于key-value持久方式的Thin，之所以起这个名字主要是这个持久框架很纤薄。
转载地址：http://nmtci.baihongyu.com/