系统分析与设计 -- hw13

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

  【答】
  软件架构（Architecture）就是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为，架构用于指导大型软件系统各个方面的设计。

  框架（framework）是特定语言和技术的架构应用解决方案，是具体语言和技术相关的。框架是集成了代码和多种第三方解决方案的工具，让开发人员聚焦业务逻辑代码而不是技术实现。

  框架与架构之间的联系：
  框架是特定语言和技术的架构应用解决方案，是一种或多种架构的组合的实现，框架不是架构，框架比架构更具体。软件通过架构，可以设计出很多不同的框架。

• 以你的项目为案例

  • 绘制三层架构模型图，细致到分区
    
  • 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

  【答】三层架构就是将业务分为表示层（UI层），业务逻辑层（BLL层）和数据访问层（DAL层）。

  表示层：用于显示数据和接收用户输入的数据，只提供软件系统与用户交互的界面。

  业务逻辑层：业务逻辑层是表示层和数据访问层之间的桥梁，专门负责处理用户输入的信息，或者是将这些信息发送给数据访问层进行保存，或者是通过数据访问层从数据库读出这些数据，进行逻辑处理如验证等。

  持久化层（数据访问层）：只负责对数据的访问存取增删修改工作。

三层架构的优点是可以充分把软件开发任务分解，使得软件的系统结构更清楚，软件开发工作分工更明确，有利于团队合作开发，有利于后期的维护和升级。

由于层和层之间的依赖关系降低，各层的开发任务可以同步进行，提高了开发效率；

• 点餐系统前端利用了小程序进行（MVC，表示层），而后端主要负责处理表示层传入的数据（业务逻辑层）以及数据的存储和访问以及数据库的实现（数据访问层）。确定好前后端负责人员以及业务需求后，表示层、业务逻辑层和数据访问层的开发工作能同步进行，而不需要知道各层的实现细节，只需要知道对方与自己负责的部分有什么交互，定下迭代周期，利用api对接，前后端就连起来了。

哪一层需要调整都不会影响其他层， 不需要对整个系统进行修改，即可维护性高，可扩展性高，体现了低耦合的思想；
从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。

• 第二次迭代时，小程序的界面需要大改，但是改动最多的只有UI层，由于业务需求基本没有改变，逻辑层的代码可继续重用，而对数据访问层的影响就更小了。

三层架构的缺点就是代码量太多,执行速度慢。

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

  1、VUE的状态管理
  

在Vue中，多组件的开发带来了很多的方便，但当项目规模变大的时候，多个组件间的数据通信和状态管理就显得难以维护。而Vuex就此应运而生。将状态管理单独拎出来，应用统一的方式进行处理，在后期维护的过程中数据的修改和维护就变得简单而清晰了。

状态：可以简单理解为数据
集中存储：Vue只关心视图，我们需要一个仓库（Store）来存储数据，而且是所有的数据集中存储，视图和数据就可以分析。
管理：除了存储，还可以管理数据，也就是计算、处理数据。
所有组件状态：所用的组件共用一个仓库（Store），也就是一个项目只有一个数据源。

• Vuex的核心部分：

  • State：State负责存储整个应用的状态数据，一般需要在使用的时候在根节点注入store对象，后期就可以使用this.$store.state直接获取状态

  • Getters：有时候需要从 store 中的 state 中派生出一些状态，对state中的数据过滤或者计算，作用上相当于store的计算属性

  • Mutation：更改 Vuex 的 store 中的状态的唯一方法是提交 mutation，mutation 必须是同步函数，否则调试工具拿不到正确的状态快照（如果异步修改状态的话），会破坏状态追踪

  • Action：Action 类似于 mutation，不同在于：Action 提交的是 mutation，而不是直接变更状态；Action 可以包含任意异步操作。Action 通过 store.dispatch 方法触发

  • Module：由于使用单一状态树，应用的所有状态会集中到一个比较大的对象。当应用变得非常复杂时，store 对象就有可能变得相当臃肿。为了解决以上问题，Vuex 允许我们将 store 分割成模块（module）。每个模块拥有自己的 state、mutation、action、getter、甚至是嵌套子模块。

• 完整的 Vuex 动作:
  Components( 组件 )中 methods 里面一个方法 dispatch （调用）Actions，Actions 然后 commit 对应的Mutations, 只有 Mutations 可以操作 State 中的状态数据，store 实例的状态变化反过来又通过 getters 被组件获知，组件中就重新渲染。

  2、FLUX状态管理

Flux是Facebook用于构建客户端Web应用程序的一个系统架构。它通过利用单向数据流来补充React的可组合视图组件。

• Flux将一个应用分成四个部分：

  • View： 视图层，view使用React创建的组件，也可以使用controller view模式。

  • Action（动作）：每个Action都是一个对象，包含一个actionType属性和一些其他属性（用来传递数据）。Action中利用Dispatcher的把具体的动作（actionType）派发到Store。

  • Dispatcher（派发器）：用来接收Actions，并将 Action 派发到 Store，即触发注册的回调方法callbacks。可以把它看作一个路由器，负责在 View 和 Store 之间，建立 Action 的正确传递路线。注意，Dispatcher 只能有一个，而且是全局的。

  • Store（数据层）：Store 保存整个应用的state状态，一旦发生变动，就提醒Views要更新页面

• 完整的 FLUX动作
  用户访问 View；View 发出用户的 Action；Dispatcher 收到 Action，要求 Store 进行相应的更新；Store 更新后，发出一个”change”事件；View 收到”change”事件后，更新页面

  3、VUE和FLUX状态管理的异同

在Vuex和FLUX中，整个应用的数据流都是单向流动的，且都是用户界面触发动作进而改变状态，从而反映到视图上的过程。
Vuex是基于flux架构的，可以发现Vuex把action细分成了action和mutation，分别应对异步场景和同步场景，由store自身充当dispatcher（负责注册/分发action/(mutation))。且Vuex的store是唯一的，而在flux中我们可以定义多个。相比起Vue，FLUX更像是一种模式，一种架构，而不是一个正式的框架。