Tiny设计原则

约定优于配置

随着J2EE各种框架的使用，你会发现要配置的内容确实是越来越多了。大量的XML充斥其中，举例：Spring配置，Hibernate配置，iBatis配置，等等等等。在Tiny框架中，也有一些配置文件，但是已经尽量进行删减，如果能够通过一些约定来减少配置的话，都会采用这原则进行解决。

减法原则

在长期的应用实践当中，我看到了太多的给程序员增加负担的作法。项目经理指挥技术经理 ，技术经理指挥技术骨干，技术骨干指挥普通开发人员。随着层级的加深，结果发现一个奇怪的事情，那就是我们的低层程序员需要会的内容是最多的，做的事情也是最多的。但是实际上，看人员结构就会明白，技术经理一般来说是最有经验、最有技能的，技术骨干次之，而低层程序员有可能是刚毕业的雏鸟程序员，或者是1-3年级生，又要会Hibernate/ibatis/jdbc，又要会Spring，还要会前台界面开发，还要会js/Flex/css/html，老天，程序员不可承受之重全压在了他们的身上。
而技术经理或项目经理，以为这样就可以得到一个成功的项目，但是实际上，往往得到提表面上比较像，实际上问题多得一塌糊涂，后续根本就不具有可维护性，最后的结果自然也就可想而知了。
Tiny框架的减法原则，与之相反，技术经理做的关键的事情要多，技术骨干次之，底层的程序员工作内容百家单纯，只做业务开发或只做界面开发。他们的工作内容单一，技术也单一，在开发过程中要严格遵循技术经理制订的开发规范（实际上不遵守不也不可以，Tiny框架有强制性来保证做到这一点）。对于技术经理来说，一切尽在掌握；对于程序员来说，我简单，我快乐。
从技术经理、技术骨干到开发人员，工作量范围与内容越来越少，也就是我们所说的减法原则。当然，工作范围与内容变少，不代表工作量变少，但是由于简单重复，所有易于上手，易于掌握，易于熟练，因此工作效率也是最高的。

下级服从上级原则

下级服从上级原则，这个道理大家都懂，但是一般情况下都是通过口头或文档约定来达到的。在执行过程中，经常就走样了，尤其是当项目进度比较紧的时候，这个时候都是抢时间，抓进度，什么规范，什么约定早就扔到一边了，这个时候，技术经理或项目经理也是知道项目在执行过程已经违反当时的规范或约定了，但是限于进度，也就做让步，最后的结果就是，随程序员去发挥了。
Tiny则不然，在许多地方，都有一些强制性规则，这些规则程序员即使想违背也不是可能的。比如：流程继承，一旦程序员的流程继承了技术经理或技术骨干的流程，则整个流程的处理过程就已经确定，技术经理一改，所有继承自此流程的子流程全部被改变；在页面开发过程中，技术经理或技术骨干定义了一些布局，程序员不管愿意不愿意，都会被技术经理或骨干定义的布局进行渲染。
所以在Tiny框架中，界面开发人员不可以引入新的JS文档，不可以引入新的CSS文档，不必编写布局信息。
比如：
程序写的文件about.page是下面的这个样子：

#@homepage() #@faq("关于我们") #@servicesItem("idea") 我们的目标：通过此开源项目的运作，对于J2EE应用框架中的各种概念与架构进行充分的验证与分析，达到概念清晰，理论体系完整，功能基本完成。 系统的编写，主要利用业余时间编写。 #end #@servicesItem("idea") 我们的目标：通过此开源项目的运作，对于J2EE应用框架中的各种概念与架构进行充分的验证与分析，达到概念清晰，理论体系完整，功能基本完成。 系统的编写，主要利用业余时间编写。 #end #end #@faq("主要参与者") #@servicesItem("idea") 罗果：负责架构设计，核心代码编写。 #end #end #end

运行结果却是这样样子：

大图
由于框架的强制性，给我们制作的about.page添加了各种布局，所以渲染的结果比程序员写的内容要多得多。

自动组装原则

基于Tiny框架开发的应用，就象是变形金刚一样，具有强大的自动组装能力，Tiny框架的实现机理就是存在即组装，也就是说只要你依赖了相关的包，那么这个包就会起作用，就会自动组装到整个应用当中。这其中避免了大量的复杂的配置过程、复杂的引用过程。不管是java工程还是界面工程还是业务单元，只要你引用了，就可以把它无缝的集成进来。而不必担心它是不是可能正常运行。实际上，自动组装能做到，才可以更好进行模块化分割。

模块化原则

Tiny框架把模块化，作为一条重要的原则，主要是从以下方面考虑：
1.便于开发
2.便于测试
3.便于复用。
所以，Tiny框架中的工程数会非常多，公用工程、基础工程、插件工程、UI工程、BU等等，由于工程划分合适，所以复用起来就更方便。

配置集中原则

我们看到了太多配置复杂的工程，所以我们对配置进行了区分，即在开发期要修改的配置还是在发布期要修改的配置。
所谓开发期要修改的配置是指开发人员自己希望做得比较灵活一些，因此增加的配置信息，这些信息一旦发布以后就会不再被修改；另外一部分配置是说，在做的过程中不能确定是什么，需要使用者在后面配置的参数。
我们这里所说的配置，主要是指后者。
在Tiny框架中，采用了配置信息集中的方式，把所有可能会修改的配置信息都集中到一个配置文件当中。这样要修改的话，只需要修改一个配置文件即可。
这对于开发人员、配置管理员、技术支持人员、工程人员等说，都是非常方便的。安装配置手册也更容易使用，便容易学习。