架构建模

lesson13

Posted by Hanxu on June 3, 2018

第13周

本周学习了软件架构相关的知识,以下是lesson13的作业内容。


架构建模-lesson13

1. 描述软件架构与框架之间的区别与联系

1.1 基本定义

  • 软件架构

    软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。

    各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

    在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。

  • 框架

    软件框架是面向领域(如 ERP、计算领域等)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供了一些定义良好的可变点以保证灵活性和可扩展性。

    也就是说软件框架是领域分析结果的软件化,是领域内最终应用的模板。

1.2 区别

** 框架是软件,架构不是软件。**

框架是一种特殊的软件,它并不能提供完整无缺的解决方案,而是为你构建解决方案提供良好的基础。框架是半成品。典型地,框架是系统或子系统的半成品;框架中的服务可以被最终应用系统直接调用,而框架中的扩展点是供应用开发人员定制的“可变化点”。

软件架构不是软件,而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后,这些架构决策将体现在最终开发出的软件系统中;当然,引入软件框架之后,整个开发过程变成了“分两步走”,而架构决策往往会体现在框架之中。

软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循,但任何一段具体的代码都代表不了架构。

架构一般针对议和行业或一类应用,是技术和应用的完美结合。

框架比较小,很多表现为中间件,框架一般是从技术角度解决同类问题,从技术的横切面来解决实际应用问题。

1.3 联系

软件架构是引导如何设计软件框架的重要决策。它决定了软件系统如何划分,在一定程度上描述了被划分的各个部分之间的静态、动态关系。软件架构的决策体现在软件系统的框架中。

引用《面向模式的软件体系结构(第一卷)》中为框架所下的定义:

框架是一个可实例化的、部分完成的软件系统或子系统,它为一组系统或子系统定义了架构,并提供了构造系统的基本构造块,还为实现特定功能定义了可调整点。在面向对象环境中,框架由抽象类和具体类组成。(A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made. In an object-oriented environment a framework consists of abstract and concrete classes.)

2. 以你的项目为案例

2.1 绘制三层架构模型图,细致到分区

lesson13

2.2 结合你程序的结构,从程序员角度说明三层架构给开发者带来的便利

  • 结构清晰、耦合度低
  • 可维护性高,可扩展性高
  • 利于开发任务同步进行
  • 容易适应需求变化

3. 研究VUE与Flux状态管理的异同

3.1 基本定义

  • VUE状态管理

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态,并以相应的规则保证状态以一种可预测的方式发生变化。 借鉴了 Flux、Redux、和 The Elm Architecture。与其他模式不同的是,Vuex 是专门为 Vue.js 设计的状态管理库,以利用 Vue.js 的细粒度数据响应机制来进行高效的状态更新。

vuex 就是把需要共享的变量全部存储在一个对象里面,然后将这个对象放在顶层组件中供其他组件使用。

将vue想作是一个js文件、组件是函数,那么vuex就是一个全局变量,只是这个“全局变量”包含了一些特定的规则而已。

  • Flux状态管理

Flux是由Facebook提出的,用于组织应用的一种架构,它基于一个简单的原则:数据在应用中单向流动。这就是所谓的“单向数据流”。

简单的记法是把数据比作鲨鱼:鲨鱼只能向前游。

3.2 同

  • 都是状态管理的方式;
  • 都用store来存储状态;
  • 都提供数据驱动的、可组合搭建的视图组件。

3.3 异

  • 多个组件共享状态的问题

    由于Flux架构有多个store,我们的应用遇到多个组件共享状态时,单向数据流的简洁性很容易被破坏:

    • 多个视图依赖于同一状态。
    • 来自不同视图的行为需要变更同一状态。
  • 问题的解决

    • 对于问题一,传参的方法对于多层嵌套的组件将会非常繁琐,并且对于兄弟组件间的状态传递无能为力。
    • 对于问题二,我们经常会采用父子组件直接引用或者通过事件来变更和同步状态的多份拷贝。以上的这些模式非常脆弱,通常会导致无法维护的代码。
  • 最终解决方案

    Vue状态管理把组件的共享状态抽取出来,以一个全局单例模式管理。 在这种模式下,我们的组件树构成了一个巨大的“视图”,不管在树的哪个位置,任何组件都能获取状态或者触发行为。

    另外,通过定义和隔离状态管理中的各种概念并强制遵守一定的规则,我们的代码将会变得更结构化且易维护。