返回系统管理员博客列表

 序言

熟悉了TINY相关开源内容的同学都有一个印象,那就是Tiny框架的目录分得非常细,比如Tiny工程的目录结构是下面的样子的:

比如TinyUiEnterprise项目的目录结构是这样的:

再比如,我们开源的软件开发过程管理软件的地目录结构是这样的:

有少许的人看了之后,深以为然,而更多的人看了之后却觉得莫名其妙。所以今天就乱弹一下模块化。

什么是模块化?

百度了一下,发现下面的说法非常经典,就此引用一下:模块化是一种处理复杂系统分解为更好的可管理模块的方式

百度百科中,关于模块化设计是这样描述的:



模块化设计,简单地说就是程序的编写不是开始就逐条录入计算机语句和指令,而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来,并定义和调试好各个框架之间的输入、输出链接关系。逐步求精的结果是得到一系列以功能块为单位的算法描述。以功能块为单位进行程序设计,实现其求解算法的方法称为模块化。模块化的目的是为了降低程序复杂度,使程序设计、调试和维护等操作简单化。

前半拉和我想表述的意思没有太大关系,大家只要看我加粗变红了的部分,就可以了。

TINY框架模块化之后的效果


  1. 随心所欲:想要啥就要啥,不想要啥就不要啥
  2. 自动组装:只要通过POM依赖或去除依赖,就可以增加或去除某一功能及其相应配置

这么说说可能比较抽象,那我说几个场景。

比如:我们经常要写Servlet、Listener、Filter,而按照J2EE早期规范,这些东西的使用是要在web.xml中配置一些内容的,而这些配置的增加或删除就会导致程序的设计和调试的复杂化,而且用了Tiny框架的模块化方面的支持,程序员只要按规范开发这些东西就好,而不必对web.xml进行相关的修改,是不是对于开发和使用都非常方便了?

比如:我们要做一个UI组件,UI组件一般会涉及到各种JS资源、CSS资源、图片、视频、字体等静态资源,按照HTML规范,我们的开发人员要使用一个UI组件,一般情况下是要引入JS、CSS资源的,而引入的顺序又是非常有讲究的,如果程序员只是依赖一个Jar包就可以,而不用关心所有的这些静态资源的位置和处理,也不用关心JS、CSS的引入,是不是对于开发和使用都非常方便了?

比如:我们在开发项目的时候,一种情况下是整个项目都放在一起的,如果能把一个完整的项目分成多个高内聚低耦合的许多个模块,那么对于开发、测试、部署是不是更加方便?是不是就更容易复用?

当然,这里举的例子还只是冰山一角。

接下来看看一张TINY框架的架构图

实际上,最终我们要把所有的软件资产都向资产库迁移--而资产库中都是我们的一个一个或小或大的模块,甚至于我们的业务单元也变成资产库中的资产。

这个时候我们的发布模式就变成下面的样子:


一个软件应用的构建只不过是制订发布计划、资产选取和参数配置而已。

总结

这里只是举了几个简单的场景,但是为了实现模块化,TINY框架做了大量的工作,解决的各种问题也多了去了。所以,模块化不是想做就可以做的,它是一个系统性工程,而系统性工程其复杂度与实现难度都是非常高的。

限于篇幅,今天只是简单乱弹了一下,感兴趣的同学可以在下面留言或通过其他方式进行探讨。


 
相关信息
     标签
       附件
      文件 标题 创建者

      评分 0次评分

      返回顶部