软件架构与框架

区别与联系

定义

• 软件框架是面向领域（如ERP、计算领域等）的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供了一些定义良好的可变点以保证灵活性和可扩展性。也就是说软件框架是领域分析结果的软件化，是领域内最终应用的模板。
• 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

参见：软件框架和软件架构的区别?

说说区别加深理解

我们可以关注一下定义中加粗部分的本质：框架是一种特殊的软件；架构是比具体代码高一个抽象层次的概念。

软件框架会包含一些代码——一系列完成计算的模块，即构件；包含使用这个框架的规则和约束——构件之间的关系及交互机制、一系列可变点等。在框架的基础上根据需要完成自定义的部分才能成为最终的软件产品。
软件架构是可以用文档和逻辑架构图（像下面那样）来表达的。它制定了领域问题的一套解决方案，关注大局而忽略细节，描述了计算组件及组件之间的交互，也可以说包含了一系列的决策.。

说白了，虽然这两个词语在日常使用中是近义词，但在这里讨论的时候，一个（架构）仍然指软件核心和主干部分的东西，另一个（框架）却更像是一套为了方便别人套用的模具。

站在高处看联系

（1）为了尽早验证架构设计，或者处于支持产品线开发的目的，可以将关键的通用机制甚至整个架构以框架的方式进行实现；
（2）业界（及公司内部）可能存在大量可供重用的框架，这些框架或者已经实现了软件架构所需的重要架构机制，或者为未来系统的某个子系统提供了可扩展的半成品，所以最终的软件架构可以借助这些框架构造。

参见：架构和框架的区别

三层架构模型图例

上图为一个扫码点餐系统的逻辑架构图，以此为例，我们说说经典的三层架构给开发者带来的便利。
首先，产品结构合理，模块的的职责明确，具有高内聚性，模块间耦合性较低。程序员能够更有针对性的编程，更有序地分工合作。
其次，三层架构逻辑上分离了UI设计、领域关系、后台实现的工作团队里各人能专注地做自己的事。例如我们的UI层就分别由两个同学完成小程序端和后端的任务，他们只需要拿到设计稿和业务文档就可以进行开发。
最后，层次间的联系由一些接口负责，关注这些接口内部的逻辑，可以清楚方便地对接和测试。

VUE 与 Flux 状态管理的异同

MVC架构我们都知道，当业务逻辑很复杂，model与controller之间的关系也很复杂的时候，我们就会需要统一管理controller（或者是MVP架构里面的presenter）的变化。这就是所谓状态管理的出众，也是二者的相同之处。

不同之处在于解决方案：

flux

它分为四层：view视图层、action层、dispatcher派发层、store仓库层。
状态发生变化时各层的响应是：view——>action——>dispatcher——>store返回——>dispatcher——>view。

vuex

vuex核心是：

• state：存放多个组件共享的状态（数据）
• mutations：存放更改state里状态的方法，用于变更状态，是唯一一个更改状态的属性
• getters：将state中某个状态进行过滤，然后获取新的状态，类似于vue中的computed
• actions：用于调用事件动作，并传递给mutation
• modules：主要用来拆分state

状态发生变化时各层的响应是：vueComnent——>(dispatch)Action——>（commit）——>Mutations——>（mutate）State——>（render）VueComponent

特别的

vuex多个组件调用一个状态，将原来组件与组件之间的状态传递改成组件与仓库之间的传递，它适用于构建大型的项目。
如果不是大型项目，使用vuex会使代码更加繁琐。vue本身是针对组件编程的框架，层层组件之间的数据传导相当麻烦。而独立于组件出现的flux，天然的完成了数据传导与presenter管理两个麻烦问题。

参考：
也说说状态管理flux/redux/vuex
flux，redux，vuex状态集管理工具之间的区别