本文就是 视图与逻辑分离之道序篇
中的彩蛋, " 猜一猜复杂的业务逻辑应该怎么处理", 快来了解一下吧
了解 GetArch
❓ 为什么做GetArch
GetArch源于一颗热爱编程的
Flutter 状态管理五花八门, 各种"快速开发模板"也悄然流行起来，但是Dart软件架构却很少有人研究.
我认为这可能与目前国内软件普遍采用前后端分离设计，让App内部没有太多业务逻辑, 亦或是Flutter开发者大多来自前端, 主要关注UI展示而对软件架构不重视导致的.
随着Serverless的崛起,借助Flutter的跨平台优势, 产品的业务逻辑重心将会逐步远离服务器,转移到个人设备上. 那么为软件设计一个高内聚,低耦合,方便多人协同开发的架构至关重要.
这并不是说, 个人开发的独立软件就没有考虑架构的必要.
软件架构的意义就在于让持续开发的成本最小化, 这也是业界 面向过程编程迅速被面向对象编程淘汰的根本原因.
站在巨人的肩膀上, 结合实际开发需求, GetArch从构思成为现实.
GetArch特性 & 解决的问题
- 拒绝重复劳动: 扔掉需要删删改改的"开发模板"吧
- 完全解耦: 不止是视图与逻辑之间
- 模块化设计: 灵活替换任何代码模块, 让App化身忒修斯之船, 追求极致的代码复用率
- 轻松上手: 预置QuickStart等模块, 成为搭建应用的脚手架, 帮助你专注于业务逻辑 (如果Flutter不提供 material.dart 和 cupertino.dart, 那开发时长可能得加倍)
- 无副作用: 在已有的项目中依然可以引入GetArchCore, 不会排斥已有代码, 加入GetArch生态, 何必重新开始?
- 岂止于Flutter? GetArchCore不依赖于Flutter SDK, 你可以基于GetArch搭建一个后端服务, 或者让App中的业务逻辑搬到后台.
引入GetArch的利弊
很多来自前端的开发者可能不太适应非UI代码部分作为程序的主体, 认为这样做是在"画蛇添足".
我认为, 是否引入架构, 应当从开发成本的角度考虑.
如果你的程序编写完毕之后就无需添加新的功能, 并且应用功能独特, 未来都没有复用的需求, 那么设计一个架构, 再区分各个模块确实没有必要, 能用就行. 强行引入架构, 徒增前期开发成本, 得不偿失.
但是如果程序还需要持续维护, 那么使用一个设计合理的架构, 以降低迭代开发成本, 还是十分必要的.
GetArch的愿景
GetArchCore完全开源, 任何遵循GetArch架构设计, 实现GetArchCore中相应接口的App都可以成为其他App的一个模块, 我希望能够有更多的人加入GetArch生态, 并让更多的人从GetArch中获益, 让GetArch终结重复造无意义轮子的历史.
GetArch —— Dart 软件架构设计的终极解决方案
传送区
GetArch 宇宙
将get_arch_core添加到yaml中, 实现对应的接口, 所有基于GetArch的程序都能成为你的轮子!
GetArch宇宙欢迎你的加入
- GetArchCore GitHub | Pub
GetArch 核心模块, 所有使用GetArch架构的程序都依赖于GetArchCore.
- GetArchQuickStart GitHub | Pub
快速开始基础设施包, 里面包含了 Http请求, Socket, 本地存储, Dialog的基础实现, 帮助使用者专注于App的业务逻辑功能
- GetState GitHub | Pub
GetState是一个基于MVVM的状态管理package.
GetState目前并不依赖于GetArchCore, 但是作为GetState的作者, 我希望更多的人 尝试使用GetState
当然, 后续版本的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
GetArch设计理念
软件开发唯一的真理是“软件必然修改”
软件架构存在的意义就在于" 如何让软件适应需求变化的成本做到最低".
实体类
首先, 思考一个问题:
"作为一个面向对象的应用软件, 其最本质的, 最核心的东西是什么?"
答案当然是"对象", 对象所拥有的属性与动作, 构成了软件的行为, 通过各个对象之间的交互, 完成软件设计时所要求的功能.
对象不依赖任何其他事物, 是构成一个面向对象程序的最基本的要素.
用例
有了对象, 程序还需要对外界不同的请求做出不同的回应, 显然, 用例(UseCase)只依赖于对象, 描述了对象的动作和各对象之间的交互, 没有对象, 用例就没有存在的意义.
用例不依赖除对象之外的任何其他事物.
接口
无论是键盘输入, 语音输入, 还是从数据库读取, 从网络访问, 程序总是需要一个接口以输入数据.
同样的,无论是通过命令行打印, 还是通过图形界面绘制输出, 程序总是需要一个方式向外界传递数据处理的结果.
作为接口, 它一定不是具象化的, 就好比USB接口, 总是可以接入各种符合USB标准的设备, 而不是只为某一种设备服务.
接口不依赖于对象和用例之外的其他事物.
基础设施
从抽象到具体, 从特定到普适. 对于程序而言, 最不重要的就是"数据从哪输入", "数据输出到哪"了.
例如一个"读书App", 要实现"展示电子书"的功能, 那么电子书是从数据库读取, 还是从SD卡读取, 亦或是从网络下载, 这些都只是数据输入方式, 如果说仅仅是因为要把一个原本只能从SD卡读取电子书的软件, 改造成能够从网络下载电子书的软件, 需要花费巨大的力气重构的话, 那这真是个极其失败的软件.
基础设施应该是一个软件中替换成本最低的部分
小结
GetArch 架构层次展示
GetArch目录结构
以上目录结构自上而下的顺序对应相关层次的上下次序, 在IDE中目录结构并不一致, 不要看错了.
这张图可能就是本文最有价值的部分了, 注意观察
写在最后
GetArchCore 项目地址
本文是一篇介绍性的文章, GetArch使用教程将在后续的文章中讲解, 敬请期待