本文就是 视图与逻辑分离之道序篇
中的彩蛋, "💡 猜一猜复杂的业务逻辑应该怎么处理", 快来了解一下吧😉
了解 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终结重复造无意义轮子的历史.
</br></br>
GetArch —— Dart 软件架构设计的终极解决方案
</br></br>
🛸 传送区
GetArch 宇宙 🌌
将get_arch_core添加到yaml中, 实现对应的接口, 所有基于GetArch的程序都能成为你的轮子!
GetArch宇宙欢迎你的加入😎
GetArch 核心模块, 所有使用GetArch架构的程序都依赖于GetArchCore.
快速开始基础设施包, 里面包含了 Http请求, Socket, 本地存储, Dialog的基础实现, 帮助使用者专注于App的业务逻辑功能
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
</br>
💡 GetArch设计理念
软件开发唯一的真理是“软件必然修改”
软件架构存在的意义就在于" 如何让软件适应需求变化的成本做到最低".
👴 实体类
首先, 思考一个问题:
"作为一个面向对象的应用软件, 其最本质的, 最核心的东西是什么?"
答案当然是"对象", 对象所拥有的属性与动作, 构成了软件的行为, 通过各个对象之间的交互, 完成软件设计时所要求的功能.
对象不依赖任何其他事物, 是构成一个面向对象程序的最基本的要素.
🤙 用例 🏃 🕺 🏌
有了对象, 程序还需要对外界不同的请求做出不同的回应, 显然, 用例(UseCase)只依赖于对象, 描述了对象的动作和各对象之间的交互, 没有对象, 用例就没有存在的意义.
用例不依赖除对象之外的任何其他事物.
🙏 接口 📭
无论是键盘输入, 语音输入, 还是从数据库读取, 从网络访问, 程序总是需要一个接口以输入数据.
同样的,无论是通过命令行打印, 还是通过图形界面绘制输出, 程序总是需要一个方式向外界传递数据处理的结果.
作为接口, 它一定不是具象化的, 就好比USB接口, 总是可以接入各种符合USB标准的设备, 而不是只为某一种设备服务.
接口不依赖于对象和用例之外的其他事物.
🦶 基础设施 🛴 🚲 🛵
从抽象到具体, 从特定到普适. 对于程序而言, 最不重要的就是"数据从哪输入", "数据输出到哪"了.
例如一个"读书App", 要实现"展示电子书"的功能, 那么电子书是从数据库读取, 还是从SD卡读取, 亦或是从网络下载, 这些都只是数据输入方式, 如果说仅仅是因为要把一个原本只能从SD卡读取电子书的软件, 改造成能够从网络下载电子书的软件, 需要花费巨大的力气重构的话, 那这真是个极其失败的软件.
基础设施应该是一个软件中替换成本最低的部分
小结
GetArch 架构层次展示
GetArch目录结构
以上目录结构自上而下的顺序对应相关层次的上下次序, 在IDE中目录结构并不一致, 不要看错了.😀
🌟这张图可能就是本文最有价值的部分了, 注意观察
</br></br></br>
写在最后
本文是一篇介绍性的文章, GetArch使用教程将在后续的文章中讲解, 敬请期待💖
