系统分析与设计 HW8

系统分析与设计  HW8


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

 软件架构就是把系统分解为一些部件,描述这些部件的职责及它们之间的协作行为。架构模式 (style) 是特定领域常见问题的解决方案,它是是业界长期最佳实践的总结,有助于我们理解系统 big picture、评估产品结构的合理性。

 框架是特定语言和技术的架构应用解决方案。框架是具体语言和技术相关的;框架是一种或多种架构的组合的实现;框架是集成了你的代码和多种第三方解决方案的工具,让你聚焦业务逻辑代码而不是技术实现

2、以你的项目为案例

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

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

    • 每个层或包的职责是清晰的,模块化并可扩展的。系统分析的每个类会分明确的放置。
    • 提供了隐式的程序复用准则。
    • 每个层涉及的技术是明确的。这使得程序员可以通过快速培训上岗。
    • 通过依赖估计项目变化产生的工作量。
    • 开发次序和重要性是明确的。领域模型、基础模块(用户和基础数据的DTO和Service必须优先开发与测试),减少这些模块的错误,特别是领域模型设计失误,是项目成功的关键。
    • 并行开发支持。利用前后端分离,实现并行开发。

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

 在 Flux 这种架构当中,Views 查询 Stores(而不是 Models),并且用户交互将会触发 Actions,Actions 则会被提交到一个集中的 Dispatcher 当中。当 Actions 被派发之后,Stores 将会随之更新自己并且通知 Views 进行修改。这些 Store 当中的修改会进一步促使 Views 查询新的数据。Flux 与传统的 MVC 的主要区别在于查询和更新的分离。在 Flux 里,View 从 Store 获取的数据是只读的。而 Stores 只能通过 Actions 被更新,这就会影响 Store 本身而不是那些只读的数据。

 当访问数据对象时,一个 Vue 实例只是简单的代理访问。Vue 使用简单的 store 模式,所有 store 中 state 的改变,都放置在 store 自身的 action 中去管理。这种集中式状态管理能够被更容易地理解哪种类型的 mutation 将会发生,以及它们是如何被触发。当错误出现时,我们现在也会有一个 log 记录 bug 之前发生了什么。组件不允许直接修改属于 store 实例的 state,而应执行 action 来分发 (dispatch) 事件通知 store 去改变,我们最终达成了 Flux 架构。

  • 异:
    • 在 Flux 中,数据流的顺序是 Views -> Actions -> Dispatcher -> Stores;在 Vue 中,数据流的顺序是 Views -> Actions -> Dispatcher -> Mutations -> Stores。
    • Flux 遇到多个组件共享状态时,单向数据流的简洁性很容易被破坏;Vue 遇到多个组件共享状态时,把组件的共享状态抽取出来,以一个全局单例模式管理。
  • 同:
    • 二者都借鉴了 CQRS ,采用了单向数据流。