本文就是 视图与逻辑分离之道序篇
中的彩蛋, "💡 猜一猜复杂的业务逻辑应该怎么处理", 快来了解一下吧😉

了解 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宇宙欢迎你的加入😎

• 🌏 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

</br>

💡 GetArch设计理念

软件开发唯一的真理是“软件必然修改”
软件架构存在的意义就在于" 如何让软件适应需求变化的成本做到最低".

👴 实体类

首先, 思考一个问题:
"作为一个面向对象的应用软件, 其最本质的, 最核心的东西是什么?"

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

对象不依赖任何其他事物, 是构成一个面向对象程序的最基本的要素.

🤙 用例 🏃 🕺 🏌

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

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

🙏 接口 📭

无论是键盘输入, 语音输入, 还是从数据库读取, 从网络访问, 程序总是需要一个接口以输入数据.
同样的,无论是通过命令行打印, 还是通过图形界面绘制输出, 程序总是需要一个方式向外界传递数据处理的结果.
作为接口, 它一定不是具象化的, 就好比USB接口, 总是可以接入各种符合USB标准的设备, 而不是只为某一种设备服务.

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

🦶 基础设施 🛴 🚲 🛵

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

例如一个"读书App", 要实现"展示电子书"的功能, 那么电子书是从数据库读取, 还是从SD卡读取, 亦或是从网络下载, 这些都只是数据输入方式, 如果说仅仅是因为要把一个原本只能从SD卡读取电子书的软件, 改造成能够从网络下载电子书的软件, 需要花费巨大的力气重构的话, 那这真是个极其失败的软件.

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

小结

GetArch 架构层次展示

GetArch

GetArch目录结构

GetArch-lib

以上目录结构自上而下的顺序对应相关层次的上下次序, 在IDE中目录结构并不一致, 不要看错了.😀

🌟这张图可能就是本文最有价值的部分了, 注意观察

</br></br></br>

写在最后

GetArchCore 项目地址

本文是一篇介绍性的文章, GetArch使用教程将在后续的文章中讲解, 敬请期待💖