- 描述软件架构与框架之间的区别与联系
【答】
软件架构（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更像是一种模式，一种架构，而不是一个正式的框架。
