标签：
什么是框架？
这个问题实际上许多“做框架”的人也不明白。 框架和库的本质不同在于：
当然，关于这两货之间的比较，还有许多个角度，但我个人觉得本质是我上面举的这些。
设计的时候应该考虑哪些问题？这个问题的答案，如果用一句话来解符号，那答案就是：要仔细考虑使用这个框架的人感受，要考虑如何让使用者感觉爽的问题。当然如果是三天两天说不清楚的方式，那就得从方法论，问题领域，设计原则等待进行阐述了。
怎样才是一个及格的框架？这个问题，用一句话解释，就是在满足上一个问题的情况下不违背基本设计原则，那么就可以算是一个及格的框架。如果用三天两天说明，那就要把所有的基本设计原则拿出来，一个个讲讲清楚，一个个说说明白。
如果满足了第一个条件，使用者是满意的，从使用来说是不错的；如果满足了第二个条件来说，从设计及实现来说是不错的。如果两个都满足了那说明，最起码是可用的及格的框架，当然也可能得分更多。
开源框架的体系与战术
顺便，今天还谈谈框架的体系与战术性角度，一家之言，说得不对还请海涵。
从军事上来说，战术性的战斗就是具体的一块无关紧要的战斗，胜就胜了，败就败了，局部互有长短，但是就全局来说没有本质的影响；而体系性的则是影响双方势力对比的重要关键点，是个死去活来的问题，是西风压倒东风还是东风压倒西风的问题。
做框架也是有同样的问题的，如果框架只能解决一个局部部分，或者说具体问题，那么就是战术性框架；比如一个Xml解析器，一个网络爬虫框架等等，都是解决具体问题的，因此不管做得怎么到位，怎么好，都是一个战术性的问题。
那么我再拿人们常说SSH框架来说，很明显Hibernate和Struts是属于战术性框架的。但是Spring则明显不同，表面上Spring本身只是提供了一系列的机制和体系，但是它本身并不做具体的某个方面的问题，他解决IOC,AOP之类的比较虚的问题，但是正因为如此，它占据了整个开源框架的核心位置，许许多多的别的框架都是非常容易被替换及剔除的，但是唯一的要剔除Spring就比较困难--或者说，剔除Spring，就需要找一个比Spring更好的方案来替代，没有找到之前，就很难真正剔除它。
偶也看了OSC上一些同学的框架的源代码，从解决具体的问题来说，技巧、慎密性、前卫性都不错，但是看来看去，感觉还是在战术性问题上打转转，也就是解决具体问题方面做得非常不错，但是在体系性方面就比较弱了。
在此，我也把自己对框架(Framework)的理解和大家交流，我的理解Framework一定是Framework框架者构建的结构性、体系性、机制性的部分，而让使用者提供实际的、业务的、具体的实现的部分；当然Framework构建者也可以提供一些实际的、业务的、具体的实现的部分，但是这只可以作为默认的、基本的实现，它在大多数的情况下都是够用的，但是在特殊情况下是可以被拿掉的，是可以被替换的。
也就是说，如果你达到上面要求，你才可以说是一个框架(Framework)，否则，你只是个Library，只是一个代码库，不能称之为一个框架。
可能有的同学们又说了，你呼扯海说了半天，你现在设计的框架怎么就是有体系性的了？？这正是我下面要解释的问题：
1.通过大量的体系性上思考，它不仅立足于解决开发问题，还考虑集成、发布、维护方面的问题。
2.构建了许多子框架，比如：流程框架，插件框架、UI框架等等，这些框架只有体系和机制及规范方面的内容，本身是不提供具体功能的，但是业务开发人员可以基于其之上进行扩展，来达成各种目标。
3.在在实现方面大都考虑有侵入性及无侵入性，也就是说如果你可以接受侵入性，那你就做起来更方便；如果你不接受侵入性，那么也可以使用Tiny框架的许多功能。
4.在集成方面下的功夫是最大的，可以方便实现自组装，也就是扔进去不用管的模式。
5.在模块化方面也是投入大量的力量，所有的资源都可以打入Jar包，不必修改web.xml就可以进行各种Web模板的加载等待。
6.战略性目标是构建一个生态圈，做UI的，做逻辑的，做业务的能够做自己擅长的事情，通力协作。
所以，正因为Tiny框架做了许多体系性的工作，可能不能直接实现某个功能，但是它的作为体系在开发、协作、维护、支持各个阶段。
当然，我们正在设计的框架中也包含了大量的解决实际问题的库和框架，同时也不拒绝各种开源框架的集成与使用。
因此，大的开发框架是个体系性的工程。所以，做开源框架之前，先要定位准确，是做战术性的还是体系性的框架，这样只做自己擅长，可控的事情，才得心应手，轻松愉快，同时又可以获得最大回报。
什么是框架？
这个问题实际上许多“做框架”的人也不明白。 框架和库的本质不同在于：
当然，关于这两货之间的比较，还有许多个角度，但我个人觉得本质是我上面举的这些。
设计的时候应该考虑哪些问题？这个问题的答案，如果用一句话来解符号，那答案就是：要仔细考虑使用这个框架的人感受，要考虑如何让使用者感觉爽的问题。当然如果是三天两天说不清楚的方式，那就得从方法论，问题领域，设计原则等待进行阐述了。
怎样才是一个及格的框架？这个问题，用一句话解释，就是在满足上一个问题的情况下不违背基本设计原则，那么就可以算是一个及格的框架。如果用三天两天说明，那就要把所有的基本设计原则拿出来，一个个讲讲清楚，一个个说说明白。
如果满足了第一个条件，使用者是满意的，从使用来说是不错的；如果满足了第二个条件来说，从设计及实现来说是不错的。如果两个都满足了那说明，最起码是可用的及格的框架，当然也可能得分更多。
开源框架的体系与战术
顺便，今天还谈谈框架的体系与战术性角度，一家之言，说得不对还请海涵。
从军事上来说，战术性的战斗就是具体的一块无关紧要的战斗，胜就胜了，败就败了，局部互有长短，但是就全局来说没有本质的影响；而体系性的则是影响双方势力对比的重要关键点，是个死去活来的问题，是西风压倒东风还是东风压倒西风的问题。
做框架也是有同样的问题的，如果框架只能解决一个局部部分，或者说具体问题，那么就是战术性框架；比如一个Xml解析器，一个网络爬虫框架等等，都是解决具体问题的，因此不管做得怎么到位，怎么好，都是一个战术性的问题。
那么我再拿人们常说SSH框架来说，很明显Hibernate和Struts是属于战术性框架的。但是Spring则明显不同，表面上Spring本身只是提供了一系列的机制和体系，但是它本身并不做具体的某个方面的问题，他解决IOC,AOP之类的比较虚的问题，但是正因为如此，它占据了整个开源框架的核心位置，许许多多的别的框架都是非常容易被替换及剔除的，但是唯一的要剔除Spring就比较困难--或者说，剔除Spring，就需要找一个比Spring更好的方案来替代，没有找到之前，就很难真正剔除它。
偶也看了OSC上一些同学的框架的源代码，从解决具体的问题来说，技巧、慎密性、前卫性都不错，但是看来看去，感觉还是在战术性问题上打转转，也就是解决具体问题方面做得非常不错，但是在体系性方面就比较弱了。
在此，我也把自己对框架(Framework)的理解和大家交流，我的理解Framework一定是Framework框架者构建的结构性、体系性、机制性的部分，而让使用者提供实际的、业务的、具体的实现的部分；当然Framework构建者也可以提供一些实际的、业务的、具体的实现的部分，但是这只可以作为默认的、基本的实现，它在大多数的情况下都是够用的，但是在特殊情况下是可以被拿掉的，是可以被替换的。
也就是说，如果你达到上面要求，你才可以说是一个框架(Framework)，否则，你只是个Library，只是一个代码库，不能称之为一个框架。
可能有的同学们又说了，你呼扯海说了半天，你现在设计的框架怎么就是有体系性的了？？这正是我下面要解释的问题：
1.通过大量的体系性上思考，它不仅立足于解决开发问题，还考虑集成、发布、维护方面的问题。
2.构建了许多子框架，比如：流程框架，插件框架、UI框架等等，这些框架只有体系和机制及规范方面的内容，本身是不提供具体功能的，但是业务开发人员可以基于其之上进行扩展，来达成各种目标。
3.在在实现方面大都考虑有侵入性及无侵入性，也就是说如果你可以接受侵入性，那你就做起来更方便；如果你不接受侵入性，那么也可以使用Tiny框架的许多功能。
4.在集成方面下的功夫是最大的，可以方便实现自组装，也就是扔进去不用管的模式。
5.在模块化方面也是投入大量的力量，所有的资源都可以打入Jar包，不必修改web.xml就可以进行各种Web模板的加载等待。
6.战略性目标是构建一个生态圈，做UI的，做逻辑的，做业务的能够做自己擅长的事情，通力协作。
所以，正因为Tiny框架做了许多体系性的工作，可能不能直接实现某个功能，但是它的作为体系在开发、协作、维护、支持各个阶段。
当然，我们正在设计的框架中也包含了大量的解决实际问题的库和框架，同时也不拒绝各种开源框架的集成与使用。
因此，大的开发框架是个体系性的工程。所以，做开源框架之前，先要定位准确，是做战术性的还是体系性的框架，这样只做自己擅长，可控的事情，才得心应手，轻松愉快，同时又可以获得最大回报。
标签：
原文地址：http://www.cnblogs.com/j2eetop/p/4612588.html
