So erstellen Sie ein Management-Hintergrund-Framework

Reihenfolge

Am 17. Oktober 2020 wurde ich offiziell entlassenFantastischer AdministratorDieses Vue-basierte Middle- und Background-Managementsystem-Framework. In den letzten zwei Jahren habe ich mehrere Artikel über meine Erfahrungen und technischen Zusammenfassungen bei der Entwicklung dieses Frameworks geschrieben:

• 2020 "Wie gestalte ich diese i-Tüpfelchen-Animationseffekte im Hintergrundrahmen?"
• 2020 "Lösen Sie ein für alle Mal das Multi-Level-Routing-Cache-Problem im Hintergrund basierend auf Keep-Alive"
• 2021 "Wie kann ich heute, wenn der Hintergrundrahmen homogen ist, denken und Unterschiede machen?"
• 2022 "Magie! Dieses Vue-Hintergrundframework muss das Routing nicht manuell konfigurieren"

Aber dieses Jahr bin ich für mehr als ein halbes Jahr fast verschwunden und habe keinen einzigen Artikel produziert. Neben der Pflege und Iteration des Frameworks denke ich auch über eine Frage nach, nämlich:

Wie erstelle ich ein Managementsystem-Framework?

Hast du Hände?

Das ist"VUE-Vorlage für das Hintergrundverwaltungssystem„Einige der Frameworks auf der Website sind relativ gut gemacht oder haben einen gewissen Ruf. Das ist natürlich nur die Spitze des Eisbergs. Geht man auf Gitee oder Github, um nach Schlüsselwörtern wie „backstage“ und „admin ", können Sie mehr finden. Es scheint, dass das Schreiben eines Hintergrund-Frameworks für die Front-End-Entwicklung ausreicht, wenn Sie Hände haben?

Tatsächlich sind die meisten Grundfunktionen eines standardmäßigen Hintergrundverwaltungssystems relativ einheitlich, da es keine hohe Anpassung wie bei C-Endprodukten erfordert. Eine Seiten- oder Kopfzeilen-Navigationsleiste wird automatisch durch die Konfiguration generiert; mehrere Themensätze sind zum einfachen Umschalten voreingestellt; dann werden mehrere allgemeine Module geschrieben, wie Benutzerverwaltung, Rollenverwaltung und Wörterbuchverwaltung; schließlich wird eine Anmeldeseite zur Verbesserung hinzugefügt Die folgende Autoritätssteuerung wird grundsätzlich durchgeführt.

Ist es schwierig, diese zu erreichen? Es ist nicht schwierig, für das vordere Ende reicht es, Hände zu haben. Das veranlasst viele Entwickler auch dazu, selbst zu schreiben. Interessenten werden es nach dem Schreiben fördern. Wenn das Feedback gut ist, werden sie es weiter pflegen. Wenn es kein Feedback gibt, wird es möglicherweise nach und nach zu einem Framework für den Eigengebrauch oder die Grube verlassen.

Aus diesem Grund gibt es im Internet so viele Hintergrund-Frameworks, weil ständig neue Frameworks auftauchen, und es gibt auch eine große Anzahl von Frameworks, die seit mehreren Monaten oder sogar mehr als einem halben Jahr nicht aktualisiert wurden .

Wem dienst du?

Zurück zum Thema, da wir ein Managementsystem-Framework erstellen wollen, wer definiert dieses " gut ", ist es der Kunde? Ja, aber nicht alle.

任何一款技术框架或产品，最终一定是服务于客户、服务于业务的，但做为一款管理系统框架，我认为更多还是服务于开发者，让开发者用更少的时间，完成客户或业务需求，那就是一款好的管理系统框架。

但是一个有手就能写的框架，要让开发者选择使用你的，而不是自己去写，想必肯定不是实现上面那些功能那么简单，那要如何服务好开发者呢？

如何服务？

既然确定是给开发者服务，那就需要确定开发者的痛点。好在我本身也是开发者，在公司内部业务开发中就有实际在使用，所以开发中的痛点还是比较好找的，无非以下几点：

• 通用业务组件少
• 相似业务模块需要频繁拷贝代码或文件
• 特殊场景缺少统一解决方案
• 框架本身提供API少，扩展性差

针对以上整理的几点，下面我会用几个实际的例子来介绍下我是怎么为开发者提供服务的，或者说我是怎么服务自己的。

毕竟只要我自己觉得用得爽了，其他开发者的使用体验也肯定不会太差，当然前提是拔高自我要求，以“人无我有，人有我优”做为目标。

通用业务组件少

这个痛点是相对比较容易解决的，因为市面上各种 UI 库已经能满足大部分的业务使用需求了，我只是做了一些二次封装或补充。

比如在 Element Plus 的 Cascader 组件基础上，封装了**省市区街道联动**组件，方便实现二级、三级和四级的选择联动：

再比如在 Element Plus 的 Upload 组件基础上，封装了**图片上传**组件，提供了多图排序、多图预览、文件类型和数量限制等特性：

除了对 Element Plus 进行一些二次封装外，我还补充了一些组件，比如**趋势标记**组件：

还有**搜索面板**组件：

当然不仅仅是上面介绍的这些，更多可以访问 演示站 进行查看。

我想说的就是，通用业务组件，是框架比较容易解决的一个痛点，因为它肉眼可见，通过原型图或设计稿，找出一些频繁在多个业务模块中出现的功能，就可以考虑是否可以封装成组件，从而减少开发者自己去实现的时间。

相似业务模块需要频繁拷贝代码或文件

后台系统里，一定有一些模块在界面、操作逻辑上是高度相似的，比如各个模块里的列表页，它们都有搜索功能、数据展示、分页功能。但又不完全一样，比如数据源、搜索项、列表展示字段都不一样。

对于这种场景，我的做法是通过框架预设的目标，搭配交互式的指令去生成对应的文件。小到组件和单页面的模板，大到整个模块（包含列表页、详情页、新增、编辑、删除功能一应俱全），都可以通过几个指令快速生成，如下图：

当然开发者也可以根据具体业务场景，自行扩展需要生成的模板。

特殊场景缺少统一解决方案

这一块的痛点，更多体现在框架自身的能力上，也是我认为决定框架是否好用中最大的因素。

因为上面提到了两个痛点，即使框架做得不到位，开发者也能自己想办法去解决。业务组件少可以自己写，或者找三方别人写好的组件；频繁拷贝代码也不是多大的问题，开发者可以借助编辑器的代码片段功能，或者其他方式去提高效率。

但一些稍微特殊的场景下，如果框架本身没有考虑到，那需求只能向框架妥协，毕竟不是所有开发者都有能力去完整阅读框架源码，并进行二次开发定制功能。

说了这么多，可能大家还不清楚到底有哪些特殊场景，这里我举几个我遇到的：

大家可以对比下现在正在使用的框架是否能满足这些场景下使用，也可以留言分享一些其他业务场景

1、导航栏按需隐藏

导航栏是个必备的功能，尤其是这种分栏布局的导航（主导航+次导航），既然有分栏导航，那就会有次导航能否隐藏的场景，效果如下：

我的做法是通过两个独立的配置项组合使用，实现了这一场景，分别是 切换主导航时自动跳转到次导航里第一个栏目路由 和 次导航只有一个栏目时自动隐藏 。

2、标签页合并

标签页的实现是通过路由切换来实现的，每访问一个路由就会增加一个标签页。

但有的场景需要对标签页进行合并，比如反复从列表页打开不同条目的编辑页，因为每个编辑页的路由不同，所以对应也会生成多个标签页，这时候就希望能将所有编辑页的标签页合并成一个，效果如下：

既然有编辑页合并的场景，那也会有列表页和编辑页合并的场景，比如同个模块下，不管是列表页，还是编辑页，或者其他同属于该模块下的页面，都希望能合并成一个标签页，效果如下：

这块我的做法是提供了一个合并规则的配置项，默认不合并，同时支持 根据路由name进行合并 和 根据activeMenu进行合并 两条合并规则，分别对应了上面两个场景，具体配置可参考文档介绍。

3、页面按需缓存

在了解这个场景前，我们先要知道什么是页面缓存，就是当用户离开当前页面后，再返回该页面，需要复原离开时的所有状态，这就是页面缓存。

页面缓存是一个比较常见的场景，部分框架也提供了支持，但按需缓存，也就是根据离开并访问的目标页面，判断是否需要对当前页进行缓存，举个例子：

假设 A 页面的缓存规则是，如果离开并访问 B 页面则进行缓存，访问其他页面则不缓存；或者只有离开并访问 B 页面不缓存，访问其他页面则都需要缓存。

如果是上面假设的这两个场景，按照大部分框架提供的能力（即在路由配置里提供一个页面是否开启缓存的设置项），可能就不一定能满足了，因为页面缓存只提供了两种状态，即始终缓存和始终不缓存。

而我的做法是分别提供了 cache 和 noCache 两个设置项，开发者可以对 cache 设置 true/false 值以满足页面始终缓存或始终不缓存的场景，也可以设置路由的name，实现精细化缓存控制，还是拿上面两个场景举例，就可以轻松配置成：

// A 页面离开并访问 B 页面则进行缓存，访问其他页面则不缓存
cache: 'b-route-name' // B页面路由name

// A 页面只有离开并访问 B 页面不缓存，访问其他页面则都需要缓存
cache: true,
noCache: 'b-route-name'  // B页面路由name
复制代码

更多细节可参考文档介绍。

框架本身提供API少，扩展性差

这一痛点的根本原因其实是上一个痛点造成的，因为能力少，所以能暴露出的内部方法就不多，所以能提供的 API 自然也就少了。

这里我就介绍几个简单的 API ，大家可以点预览链接看实际效果：

1、主导航切换

import useMenu from '@/utils/composables/useMenu'

const { switchTo } = useMenu()

switchTo(index)
复制代码

预览

2、主页面刷新

import useMainPage from '@/utils/composables/useMainPage'

const { reload } = useMainPage()

reload()
复制代码

预览

3、主页面最大化

import useMainPage from '@/utils/composables/useMainPage'

const { maximize } = useMainPage()

// status: true / false
maximize(status)
复制代码

预览

4、动态标题

有时候，我们需要在某个页面显示自定义的标题，而不是 meta.title 字段，比如在编辑用户的页面，显示当前用户的名称。

import useSettingsStore from '@/store/modules/settings'
const settingsStore = useSettingsStore()

onMounted(() => {
  settingsStore.setTitle('测试标题')
})
复制代码

预览

5. Registerkarte bezogen

APIs wie Öffnen, Schließen und Prüfen werden bereitgestellt.

Vorschau

Ende

Geschrieben hier, möchte ich ein wenig abschweifen.

Irgendwann in diesem Jahr hatte ich plötzlich mehr Anerkennung für den Satz „Programmierer wechseln Karriere, der am besten geeignete Produktmanager“. In der Kategorie der Programmierer halte ich die Frontend-Entwicklung für den Wechsel zum Produktmanager für besonders geeignet.

Da es den meisten Kunden egal ist, welche Technologie Sie verwenden, kümmern sie sich nur um das "Aussehen", z. B. ob die Benutzeroberfläche gut aussieht, ob die Bedienung vernünftig ist und ob die Animation flüssig ist, und den größten Teil der täglichen Arbeit der Frontend-Entwicklung beschäftigt sich damit. Wenn Sie genügend Geschäftsanforderungen ausgesetzt sind, verstehen Sie, was Kunden wollen, je besser Sie die Schmerzpunkte oder unangemessenen Stellen in den nächsten Geschäftsanforderungen schnell herausfinden und eine relativ ausgereifte Lösung bereitstellen können, die auch die Fähigkeiten und Erfahrungen eines Produktmanagers sind besitzen sollte.

Genau wie bei dem Managementsystem-Framework, das ich geschrieben habe, begnüge ich mich dieses Jahr nicht damit, neue Features anzuhäufen, sondern denke darüber nach, wie ich die Entwickler, die mein Framework verwenden, besser bedienen kann, nicht nur um ihre Bedürfnisse zu erfüllen, und sie zu machen bequem zu bedienen, wieFantastischer AdministratorDer Slogan auf der Homepage der offiziellen Website – „ Out of the box, Providing an comfortable development experience “.

Vielen Dank, dass Sie hier gelesen haben. Ich hoffe, meine bescheidene Meinung in dem Artikel kann Ihnen etwas Inspiration bringen.