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

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

了解 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使用教程将在后续的文章中讲解, 敬请期待💖