Angular2的模块架构浅谈

一、根模块、子模块与惰性加载

先说根模块。一个ng2应用至少要有一个根模块,包含ng2自带的BrowserModule,并声明为引导模块,在应用启动时将从此模块展开。
随着应用的扩大,所有的事情都在一个模块中完成难免会变乱(某种程度上看ng1应用就是这么做的,并且细分了控制器来拆分应用,这其实浪费了最顶层模块的意义),所以自然而然能想到,可以将系统分为多个模块,每个模块都只做各自的事情而互不干扰,所以进一步的思路就是,用来根模块来引导程序并管理所有子模块(通过路由定向以及为它们提供全局配置与服务实例),所有的具体业务就交给各个子模块来完成。
然后会有一个问题,那就是既然系统已经被这么多个子模块瓜分了,并且这些子模块也不可能同时全部都会被使用,也就是只有其被激活时才有用,那仍然在应用引导时从根模块加载所有子模块必然会导致性能的浪费以及拖慢执行速度。此时惰性加载模块就派上用场了,将一个子模块定义为惰性加载后,只有在通过路由激活此模块时才会开始加载此模块(并且ng2甚至支持异步预加载,即后台预加载懒加载的模块,这样当懒加载模块需要被加载时其实其已经加载完成了,又加快了响应速度)。

二、除了模块之外

每个模块都有自己的事情要做,通常包括:

  1. 引入其他模块                                 这个在第三部分细说


  2. 声明模块包含的组件、指令与管道        所有的组件、指令或管道都必须依附于某个模块,并只在此模块中可用。

  3. 定义模块提供的服务              服务也有自己所属的模块,但由于服务是全局单例的,所以只要在一个模块中提供之后,全局都通用。注:若多个模块同时提供了服务(通常发生在模块间混乱的import时),一般情况下ng2能识别并只保留一个实例,但在惰性加载的模块中则会发生不可预计的错误,所以一定要避免。

  4. 定义模块将导出的组件、指令与管道(还可以是此模块引入的模块)        与(1配合使用,同样在第三部分细说。

三、模块的关联

模块之间一定要有共享或继承资源的方式,不然的话每个子模块都必须实现可能用到的全部功能。

比如一个消息弹窗组件,不可能每个子模块都自己声明一个消息组件然后使用,这样的维护压力很大且代码严重浪费。

此时就用到了模块的引入和导出——
模块A可以引入另一个模块B,然后A就可以使用B中导出的组件、管道和指令。

当我们要使用系统指令(如ngIf、ngFor等)时,也必须引入系统模块,有一个巧妙的办法就是实现上图这样的共享模块,在引入系统模块并导出的同时再导出自定义的其他指令、组件或管道。然后所有引入了此共享模块的子模块就能使用这些系统指令和共享指令了。

有一个基础的问题是服务需不需要导出,答案是否定的。服务不需要导出,因为服务是全局单例的,一旦被初始化,就已经全局通用了,相反如果重复的导入提供了同一服务的模块就可能发生问题:
B提供服务B_S,A导入了B,C也导入了B。这种情况下ng2会找到两处B_S的提供,但ng2尚能够将其保持在一个实例B_S。但若模块C为惰性加载的模块,在C被创建时,其实会重新初始化一个实例B_S,从C跳转回到A时,又会创建一个B_S,来回每次跳转都是如此,结局就会变得混乱不堪。
对于服务更好的做法是写一个核心模块,专门提供全局服务,保证此模块只会被根模块引用一次,然后所有的子模块就都已经可以使用这些全局服务了。

四、ng2模块体系

最后给出一套ng2项目构建的体系,这也是总结归纳了ng2官网的推荐得出的ng2项目的模块体系。

总体思路就是:

> 1.根模块负责全局的路由。

> 2.核心模块负责全局服务,也可以定义一些只在根模块中使用的组件等,并只能由根模块引入一次,不再导出。

> 3.共享模块不做服务的提供,而是定义全局共享的组件等,以及帮助子模块导入系统模块,让子模块只需要导入此共享模块就够了。

> 4.子模块内部可以细分自己的子路由到具体的子组件,以及提供自己的服务等。

> 5.除了页面入口模块(即除了根模块外的具体业务模块)之外的其他子模块均考虑写成惰性加载的模块,以提升页面引导的速度减少性能浪费。

> 6.当需要一个比较通用的全局服务时,可以将其加入CoreModule,也可以再创建一个仅被根模块引入的特性模块。进一步的,甚至可以将此模块发布到npm,这就需要更强的编码能力和技术积累了。

时间: 2024-08-01 20:52:24

Angular2的模块架构浅谈的相关文章

前端架构浅谈

前端架构浅谈 0.前注 鉴于作者本人的能力有限(非常有限),并且依然在学习中,因此本文的高度和深度必然有所欠缺. 欢迎(并且非常欢迎)大家来批评指正,如果能详细的说明问题在哪里,如何解决和改正,那么就太感谢了!!! 我最喜欢听有理有据的批评了!! 本人QQ:20004604,邮箱:[email protected],期待你的交流. 1.为什么要有一个好的架构 首先明确一点,架构是为需求服务的. 前端架构存在的目的,就我个人理解来说,有以下几点: 1.提高代码的可读性. 一个好的架构,代码的可读性

C++插件架构浅谈与初步实现

一.插件架构初步介绍 想到写本博客,也没想到更好的名字,目前就先命这个名吧.说到插件架构,或许大部分IT从业者都听过或者某些牛人也自己实现过稳定高效的插件框架.目前有很多软件以及库都是基于插件架构,例如PS.我所在行业的GIS软件如Arcgis.QGIS.还比如开源图形引擎OGRE以及OSG,这些都是插件架构,通过插件架构来进行功能的扩展.那到底什么是插件架构呢?我的理解是系统运行时在需要某个功能的时候动态加载的模块,插件通常用动态链接库实现,当然也可以用静态库,例如一些嵌入式系统中,比如IOS

iOS应用架构浅谈

缘由 从事iOS工作一年多了,主要从事QQ钱包SDK开发和财付通app维护,随着对业务的慢慢熟悉,最近在思考这两款应用架构设计的思想,刚好昨天在微信里看了一篇iOS大牛对终端应用架构的分享,乘热打铁,下面浅谈下我对ios应用架构设计的理解,写的不好或不对的地方,欢迎大家拍砖,我们一起来探讨. 假如问你一个iOS or Android app的架构,你会从哪些方面来说呢? 不要急着给出你的答案,可以先在你的脑子里思考3分钟,再看下面我要讲的内容. 其实对于iOS客户端应用的架构来说,复杂度不亚于服

超融合架构浅谈

为什么叫浅谈呢,因为就是自己的观点,受知识所限难免偏颇.数据中心里面真正的东西总结起来就是三大部件:计算.存储和网络.这三大部件的演变过程是:硬件-虚拟化-融合. 在传统独立硬件时代,计算资源就是服务器,存储也是独立的硬件设备,因为服务器和存储之间的相互连接就构成了网络.不管是TCP/IP还是FC,这些构成服务器和存储之间连接的网络部分,随着服务器硬件的升级和存储的硬件的升级而成为瓶颈.为什么不把碍事的连接网络去掉,将最强的直接融合在一起,即服务器和存储硬件融合在一起,并且实现扁平化.在超融合时

iOS 应用架构浅谈

当我们讨论客户端应用架构的时候,我们在讨论什么? 其实市面上大部分应用不外乎就是颠过来倒过去地做以下这些事情: 简单来说就是调API,展示页面,然后跳转到别的地方再调API,再展示页面. App确实就是主要做这些事情,但是支撑这些事情的基础,就是做架构要考虑的事情. 调用网络API 页面展示 数据的本地持久化 动态部署方案 上面这四大点,稍微细说一下就是: 如何让业务开发工程师方便安全地调用网络API?然后尽可能保证用户在各种网络环境下都能有良好的体验? 页面如何组织,才能尽可能降低业务方代码的

iOS开发项目架构浅谈:MVC与MVVM

MVC MVC,Model-View-Controller,我们从这个古老而经典的设计模式入手.采用 MVC 这个架构的最大的优点在于其概念简单,易于理解,几乎任何一个程序员都会有所了解,几乎每一所计算机院校都教过相关的知识.而在 iOS 客户端开发中,MVC 作为官方推荐的主流架构,不但 SDK 已经为我们实现好了 UIView.UIViewController 等相关的组件,更是有大量的文档和范例供我们参考学习,可以说是一种非常通用而成熟的架构设计.但 MVC 也有他的坏处.由于 MVC 的

[nRF51822] 14、浅谈蓝牙低功耗(BLE)的几种常见的应用场景及架构(科普类干货)

蓝牙在短距离无线通信领域占据举足轻重的地位—— 从手机.平板.PC到车载设备, 到耳机.游戏手柄.音响.电视, 再到手环.电子秤.智能医疗器械(血糖仪.数字血压计.血气计.数字脉搏/心率监视器.数字体温计.耳温枪.皮肤水分计等), 再到智能家居等领域均占有一席之地. 而蓝牙低功耗(BLE)是在蓝牙4.0协议上修改以适用低功耗应用场景的一种蓝牙协议. 随着上一股智能消费类电子大潮的到来,BLE的各种应用也像雨后春笋般在市场上铺开. 如果想 紧跟蓝牙协议的最新动态 ,可以在https://www.b

浅谈HTML5单页面架构(二)——backbone + requirejs + zepto + underscore

本文转载自:http://www.cnblogs.com/kenkofox/p/4648472.html 上一篇<浅谈HTML5单页面架构(一)——requirejs + angular + angular-route>探讨了angular+requirejs的一个简单架构,这一篇继续来看看backbone如何跟requirejs结合. 相同地,项目架构好与坏不是说用了多少牛逼的框架,而是怎么合理利用框架,让项目开发更流畅,代码更容易管理.那么带着这个目的,我们来继续探讨backbone. 首

浅谈HTML5单页面架构(一)——requirejs + angular + angular-route

本文转载自:http://www.cnblogs.com/kenkofox/p/4643760.html 心血来潮,打算结合实际开发的经验,浅谈一下HTML5单页面App或网页的架构. 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs