《开源框架那些事儿12》：框架2.0的设计梳理

标签：

前面从各个角度，讲了大概11篇了。言归正传，这里讲解一个完整的框架设计实例。这里不是一个空白的描述，而是基于V1.0之后的建构。因此，整个设计过程，也会尽量少走一些弯路。一起来看看吧！

方法论
方法论决定了可以达到的高度
方法论，就是人们认识世界、改造世界的根本方法。


它是人们用什么样的方式、方法来观察事物和处理问题。概括地说，世界观主要解决世界“是什么”的问题，方法论主要解决“怎么办”的问题。


方法论是一种以解决问题为目标的体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。


方法论也是一个哲学概念。人们关于“世界是什么、怎么样”的根本观点是世界观。用这种观点作指导去认识世界和改造世界，就成了方法论。 方法论是普遍适用于各门具体社会科学并起指导作用的范畴、原则、理论、方法和手段的总和。


Tiny框架有着完整的方法论基础，在方法论的基础上构建了完整的框架构建、扩展、利用体系。

设计理念
设计理念决定了设计的目标
使用灵活：可以整个使用它，也可以只用它的一个或几个部分。Tiny构建者认为，一个完整的框架可能需要有许许多多个部分组成，但是对于实际应用的用户来说，它可能只需要其中的一部分功能。构架一定要有这种能力，可以由使用者进行点菜式，使用，避免只要用一点点功能，就要引入许许多多的内容。


学习成本低、上手容易:框架的学习成本必须非常低，这样才可以让使用者更容易上手，避免由于学习难度大而导致的学习曲线太陡、太长。


保持核心的稳定性:Tiny框架是立足于在需要稳定、安全要求非常高的应用环境中使用的，因此其稳定性就是框架构建者首要思考目标，核心部分只使用经过充验证及广泛应用的第三方包。


资产的可积累性：只有易于知识积累，才可以真正做到越用越强。

设计原则
设计原则解决目标冲突时的解决策略
约定优于配置原则-COC
不要重复你自己原则-DRY
减法原则 :减法原则是我们自己提出的，意思就是给程序员做减法。
模块化原则 :模块化对于软件开发过程中开发、高度、集成、发布、维护过程中所起的作用及节省或花费的巨大成本。因此提出了Business Unit的概念，使得与模块相关的所有内容都可以放在一起。
自动组装原则 :在整个Tiny框架的构建过程中，都非常注重集成过程的自动组装，要求做到扔进去不用管，由框架自动集成。
下级服从上级原则 :Tiny框架则从框架层级做了限制，使得下级必须服务上级。
单一原则 :通过单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的胡子眉毛缕不清的问题，同时也避免了不恰当的依赖及模板引用。
集中配置原则 ：在Tiny框架我们对配置做了大量的工作，一个是COC方式，如果不配，则采用系统默认的值；一个是集中原则：把需要人工需要配置的内容都集中起来统一配置；一个是对于不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。

生态圈
生态圈决定了是否可以持续性发展
只有形成完整的开源生态圈，开源才能生存、发展。


只有输出没有输入的模式不可能得到持续发展。


Tiny开源生态圈，包含了Tiny框架、Tiny开源组件、Tiny商业组件、Tiny技术支持、Tiny咨询、Tiny培训等，具有较强市场竞争力和可持续发展的体系，展现了一种新的软件产业发展模式。


不管您处在生态圈的哪个位置，您都会有所付出有所收获，这正是生态圈的意义及可持续发展的动力所在。

模块化
模块化能力决定了业务模块治理的优劣
Tiny框架在模块化方面进行了深入的研究和实践。


Tiny业务开发过程中的任何内容都可以放入Jar包当中去，包含Java类，静态资源，JSP等等，所以一个业务模块是不是被工程引用，只要引入对应的Jar包，就可以引入此业务模块；只要把某个业务模块的Jar包移除就可以彻底移除此业务模块。


Tiny框架的业务单元具有非常好的独立性、替换性和通用性。

还有许多不再一一贴图。

《开源框架那些事儿12》：框架2.0的设计梳理

标签：

原文地址：http://blog.csdn.net/cndes/article/details/46460451