转载

视图与逻辑分离之道1- GetArch, 秃头拯救者 (Dart软件架构设计)

GetArch源于一颗热爱编程的 :two_hearts:

Flutter 状态管理五花八门, 各种"快速开发模板"也悄然流行起来，但是Dart软件架构却很少有人研究.

我认为这可能与目前国内软件普遍采用前后端分离设计，让App内部没有太多业务逻辑, 亦或是Flutter开发者大多来自前端, 主要关注UI展示而对软件架构不重视导致的.

随着Serverless的崛起,借助Flutter的跨平台优势, 产品的业务逻辑重心将会逐步远离服务器,转移到个人设备上. 那么为软件设计一个高内聚,低耦合,方便多人协同开发的架构至关重要.

这并不是说, 个人开发的独立软件就没有考虑架构的必要.

软件架构的意义就在于让持续开发的成本最小化, 这也是业界面向过程编程迅速被面向对象编程淘汰的根本原因.

站在巨人的肩膀上, 结合实际开发需求, GetArch从构思成为现实.

:wrench: GetArch特性 & 解决的问题

:pill: 拒绝重复劳动: 扔掉需要删删改改的"开发模板"吧
:closed_lock_with_key: 完全解耦: 不止是视图与逻辑之间
:package: 模块化设计: 灵活替换任何代码模块, 让App化身忒修斯之船, 追求极致的代码复用率
:smile: 轻松上手: 预置QickStart等模块, 成为搭建应用的脚手架, 帮助你专注于业务逻辑 (如果Flutter不提供 material.dart 和 cupertino.dart, 那开发时长可能得加倍:grinning:)
:+1: 无副作用: 在已有的项目中依然可以引入GetArchCore, 不会排斥已有代码, 加入GetArch生态, 何必重新开始? :sunglasses:
:muscle: 岂止于Flutter? GetArchCore不依赖于Flutter SDK, 你可以基于GetArch搭建一个后端服务, 或者让App中的业务逻辑搬到后台.

:balloon: 引入GetArch的利弊

很多来自前端的开发者可能不太适应非UI代码部分作为程序的主体, 认为这样做是在"画蛇添足".

我认为, 是否引入架构, 应当从开发成本的角度考虑.

如果你的程序编写完毕之后就无需添加新的功能, 并且应用功能独特, 未来都没有复用的必要, 那么设计一个架构, 再区分各个模块确实没有必要, 能用就行. 强行引入架构, 徒增前期开发成本, 得不偿失.

但是如果程序还需要持续维护, 那么使用一个设计合理的架构, 以降低迭代开发成本, 还是十分必要的.

:sparkling_heart: GetArch的愿景

GetArchCore完全开源, 任何遵循GetArch架构设计, 实现GetArchCore中相应接口的App都可以成为其他App的一个模块, 我希望能够有更多的人加入GetArch生态, 并让更多的人从GetArch中获益, 让GetArch终结重复造无意义轮子的历史.

GetArch—— Dart 软件架构设计的终极解决方案

传送区

GetArch 宇宙 :milky_way:

将get_arch_core添加到yaml中, 实现对应的接口, 所有基于GetArch的程序都能成为你的轮子!

GetArch宇宙欢迎你的加入:sunglasses:

:earth_asia: GetArchCore GitHub | Pub

GetArch 核心模块, 所有使用GetArch架构的程序都依赖于GetArchCore.

:rocket: GetArchQuickStart GitHub | Pub

快速开始基础设施包, 里面包含了 Http请求, Socket, 本地存储, Dialog的基础实现, 帮助使用者专注于App的业务逻辑功能

:memo: GetState GitHub | Pub

GetState是一个基于MVVM的状态管理package.

GetState目前并不依赖于GetArchCore, 但是作为GetState的作者, 我希望更多的人尝试使用GetState :wink:

当然, 后续版本的GetState肯定会加入GetArch生态, 以获得一致的使用体验.

GetArch架构设计参考链接

The Clean Architecture
Applying The Clean Architecture
Clean Architecture Essentials
Implementing Clean Architecture - What is a use case?
Applying Clean Architecture on Android
Explicit architecture

:bulb: GetArch设计理念

软件开发唯一的真理是“软件必然修改”

软件架构存在的意义就在于" 如何让软件适应需求变化的成本做到最低".

:older_man: 实体类

首先, 思考一个问题:

"作为一个面向对象的应用软件, 其最本质的, 最核心的东西是什么?"

答案当然是"对象", 对象所拥有的属性与动作, 构成了软件的行为, 通过各个对象之间的交互, 完成软件设计时所要求的功能.

对象是面向对象程序的根本. 对象不依赖任何其他事物.

用例 :runner:

有了对象, 程序还需要对外界不同的请求做出不同的回应, 显然, 用例(UseCase)只依赖于对象, 描述了对象的动作和各对象之间的交互, 没有对象, 用例就没有存在的意义.

用例不依赖除对象之外的任何其他事物.

:pray: 接口 :mailbox_with_no_mail:

无论是键盘输入, 语音输入, 还是从数据库读取, 从网络访问, 程序总是需要一个接口以输入数据.

同样的,无论是通过命令行打印, 还是通过图形界面绘制输出, 程序总是需要一个方式向外界传递数据处理的结果.

作为接口, 它一定不是具象化的, 就好比USB接口, 总是可以接入各种符合USB标准的设备, 而不是只为某一种设备服务.

接口不依赖于对象和用例之外的其他事物.

基础设施 :bike:

从抽象到具体, 从特定到普适. 对于程序而言, 最不重要的就是"数据从哪输入", "数据输出到哪"了.

例如一个"读书App", 要实现"展示电子书"的功能, 那么电子书是从数据库读取, 还是从SD卡读取, 抑或是从网络下载, 这都不是软件的根基, 如果说仅仅是因为要把一个原本只能从SD卡读取电子书的软件, 改造成能够从网络下载电子书的软件, 需要花费巨大的力气重构的话, 那么这个软件的设计真的是糟糕透了.

基础设施应该是一个软件中替换成本最低的部分

原文 https://juejin.im/post/5ef5b501f265da22e610cc82

正文到此结束