Access用户如何借助低代码转型为Web(B/S和移动端)开发?

时间:2024-03-10 07:20:26

转载自accessoft论坛,讲了一个Access开发者如何转型成为低代码开发者的心路历程,希望对还在做Access的朋友有所帮助。

原文标题:廉颇老矣!我为啥要抛弃Access?

我是一名企业软件的老兵,曾经用Visual Studio做过一些开发,后来转型用Access为小型的企业客户做系统的开发和维护。随着时代的进步、技术的发展,我逐渐意识到Access已现疲态,咱们Access开发者该何去何从?经历了很多尝试,我最终做了技术转型,和大家分享一些经验。

Access究竟是什么?

Access出生在1992年,1994年加入Office 4.3 Pro,成为Office的一个重要组成部分。但是与其他Office产品不同,Access集数据库和集成开发环境于一身,通常用来开发业务系统,而不是直接拿来存储数据。

 

因其界面友好容易操作,与微软Office系列办公软件集成能力强等优势,Access能大幅提高了使用者的工作效率,轻松实现在数据表中嵌入位置、声音、Excel表格、word文档等各种对象,还可以用来构建动态的数据报表和窗体等。在软件开发技术尚未取得实质性突破,可视化编程方兴未艾的20世纪末,Access一经问世,便以实用性、灵活性的优势,赢得了企业系统开发者的好评。

 

 

 

 

 

这其中,就包含了我。我是从Access 2003开始上手的, Access 2007发布后不久,就从mdw派坚定的转向accdb派。除了上面粘过来的那段,Access最能吸引我的,还有能以链表的方式打开各种Excel文件,格式化文本等存储有其他业务数据的文件。这让我可以用操作数据库的方式,以SQL语言对各种数据进行查询处理。此外,我还用Access访问后台的SQL Server数据库开发,开发过前台客户端;也拿Access当数据库,用C#开发过应用。总之,在我的印象中,只要学会Access,能干的事情真实太多了。

 

很多像我一样的“Access程序员”使用这个工具开发了大量的企业应用,随着时间的推移,Access的技术限制也逐渐浮出水面。

Access尚能饭否?

谈到Access的技术限制,首当其冲是性能问题。当数据库达到100MB以上尺寸,或单个表中的记录超过百万行时,性能就会变差,基本上处于“不可用”状态。

 

运行环境也是Access的短板。使用Access开发的应用要求用户必须要安装Access,在国内推动正版化的大背景下,成本非常高。而在企业软件B/S化和移动化的时代,Access却只能安装在PC端,不支持浏览器和移动端使用,也是Access的硬伤。

 

开发语言方面Access也面临不小的挑战。Access的开发语言是VBS,语法和技术上和VB一致,属于非常老旧的开发技术,已经被行业所抛弃。社区的凋敝,让解决方案和学习资料日渐老旧,难以应对目前主流的应用场景。我的感受是,身边做Access的人越来越少,被“招聘难”、“培训难”困扰的朋友越来越多。

 

解铃还须系铃人,能够让Access突破上述限制,持续进化的只有微软。然而,据微软官方发布的消息,微软将于2020年末停止维护Access。使用Access开发企业应用的我们将何去何从?也许,是时候走出舒适区,寻找Access的替代品了。

低代码,Access的最佳替代品

当我把视野从Access移开,寻找能够快速开发企业应用的技术方案时,低代码便浮出了水面。“低代码”是 Forrester Research 于 2014 年提出的概念,指一种主要应用于企业信息化领域的快速开发技术。借助低代码,开发者无需编码即可生成企业应用的常见功能,少量编码能开发出更多扩展功能。

 

这是一个高速发展的领域,吸引了太多人的关注,一如当年的Access。从媒体报道上看,低代码与Access非常类似,都是为企业应用开发而生的技术,使用者也同样介于业务人员和专业程序员中间,即懂一些技术,但缺乏专业的编程训练(我悄悄点一下反对,但你懂的)。

 

然而,当我从百度上搜索低代码,想要了解更多产品时,却发现事情似乎没有那么简单。百度的搜索结果中充斥着大量的广告和推送信息。这些信息来自参差不齐的低代码厂商,其中还存在相互矛盾的情况。我花了几天时间,看了大量的页面,并尝试了一些产品后,终于在鱼龙混杂的低代码开发工具中找到了最适合Access开发者转型的选项。下面我将分享一下我是如何评估这些工具的,供Access开发者们参考。

如何选择一款低代码工具?

在寻找Access替代品的过程中,我给自己制定了一套标准,期望能选出一个更专业的平台,用的技术一定要是主流的,不能再走从入门到放弃的老路。这套标准的核心是以下四点:

 

l  B/S架构,支持在浏览器上使用,能支持移动端

l  能直接设计和操作数据库,有足够的可控性

l  开发效率不能比Access低,做复杂逻辑时使用主流的语言,可以能接受放弃VB

l  现有的Access数据要能复用,简化导入流程

 

此外,还有一个“加分项”:协同开发。Access不支持协同开发,我之前做的很多项目都是“一个人的战斗”,做起来很累,而且因为没有人可以查漏补缺,失败率也比较高。我希望新的功能能够支持团队开发,即使一些复杂项目,也可以快速搞定。

 

综合考虑厂商的知名度、官网的介绍内容,我选择了5款产品进行深度了解,最终结果如下表,也许不全面,见谅。

 

 

 

 

 

基于这些信息,我的初评如下,供大家参考。

l  PowerApps:微软官方推出的Access Web应用替代品。产品功能全面,如果不是因为不支持私有化部署(绑定Azure云服务),而且不支持导入现有Access数据库,我也许会将其作为首选。

l  活字格:拿奖无数的产品,中软协的行业报告都是和这家联合推出的。产品的设计思路和编程语言选择上和PowerApps接近,做出来的系统是标准的前后端分离架构,每一层都支持编程扩展,看着很专业,学习曲线可能比较陡。与PowerApps相比,活字格支持私有化部署,还支持从Access文件导入,优势很突出。

l  iVX5:之前叫iH5,有十几年的历史,在H5页面设计器领域很出名。iVX5偏重于做移动端应用,开放性偏差,自己弄了一套“编程语言”,和主流做法的差异较大。大约应该更适合业务人员拿去做一些简单场景的小应用,比如做个问卷调查啥的,很难搞定ERP甚至MES这种复杂项目。

l  宜搭:阿里巴巴的开发工具,自带光环。产品整体上偏向于toC,不支持操作数据库,开放性比iVX5还差一些。和iVX5类似,宜搭的应用场景也比较有限。

l  魔方网表:这个产品在很多互联网社区上做宣传,是最早出现在我面前的低代码产品。我一开始对其寄以厚望,然而期望越高失望越大。B/S页面粗糙且不能自定义,不支持操作数据库,没有编程接口。我感觉这款软件更像是Excel,与“开发工具”的格格不入。

 

经过初评,活字格和我的需求匹配程度最高,顺利进入试用评估环节。好在活字格支持免费试用,而且还有负责技术支持的小姐姐帮我远程解决问题,给我的评估工作带来了不小的便利。顺便提一句,小姐姐的声音好听,技术能力也非常强,绝不是花瓶,应该有很多年的项目开发经验。

面向实战的技术评估

为了确保活字格真的能担起替代Access的大任,我决定花几天时间,去学习如何用活字格开发出WMS系统中的出库功能,在开发过程中评估产品功能。之所以选择这个功能,是因为我最近用Access连续做了几个库管相关的项目,对需求场景的印象也最为深刻。

 

正式动手评估之前,我看了几部活字格的入门视频教程,了解到活字格分为设计器和服务器两部分。设计器和服务器,就像Visual Studio和IIS的关系。我使用设计器开发应用,然后发布到服务器上,最终用户拿浏览器访问就可以了。

1.   设计数据模型

使用Access开发过应用的人都知道,做系统的第一步是设计表结构,我想用活字格也不例外。打开活字格设计器的一瞬间,我感觉这就像是Excel和Access的合体,数据表的设计方式与Access类似,可以在同一个页面上设计表结构、修改数据;甚至能在表的设计页面上,直接通过关联字段设置外键关系,而不需要打开关系视图。

 

 

 

 

虽然活字格支持使用外部数据库,比如SQL Server和MySQL,但是我这次的重点是对活字格进行评估,所以直接用了内置的数据库。10分钟不到的时间,本次技术验证用的表和关系就创建完成了,轻车熟路。

2.   设计页面布局

在设计页面的时候,活字格的体验方式更像是Excel,在格子上画出页面元素,然后把表中的字段绑定到页面上就可以实现数据的展示和修改。我很难准确地形容三两下就拖拽出一个页面,点击运行按钮后,和设计器中一模一样的Web页面展现在眼前的感受,非常的震撼。这不就是我最想要的B/S系统吗,得来全不费工夫嘛。

 

 

 

趁热打铁,我在一个小时内就画出了技术验证所需的全部页面。与Access不同的是,窗体、查询和报表在活字格中统一成了“页面”:我在页面上放和表里字段对应的输入框,就成了窗体;放一个表格,拖上对应的字段,就变成了查询;再放一些图表,向Excel一样配置数据源后,就有了报表。虽然要花一些功夫来做这些页面,但是设计体验非常顺畅,也很灵活。有了格子线的参考,我很容易就做出了整齐美观的界面,比布局视图要方便很多。除了页面布局,在页面上还能直接使用Excel的公式进行逻辑判断和简单的数据处理,功能非常强大。

 

 

3.   实现业务逻辑

在用Access做开发时,布局工作完成后,我就会切换到设计视图,为按钮开发对应的事件。Access的事件对应了活字格中的命令。活字格内置了很多命令,有些在页面上运行,比如页面跳转、简单的数据表增删改查等,有些在服务端运行,比如有事务性要求的数据处理(终于可以支持真正的并发了)。配合上Excel公式,做页面跳转、数据过滤、逻辑判断和数据处理等操作都很便利。按照教学视频中讲的,命令是活字格最核心的功能,编程接口也是基于命令机制扩展出来的。直到最近交付了第一个应用,我对活字格内置的命令还没有完全吃透,大半的命令都没有用过。慢慢来吧,技多不压身。

 

下面是我整理的Access和活字格的重要概念对照表。有了这张表,我相信你也可以和我一样,快速上手活字格了。

 

 

 

参考了活字格内置的模板,我大约用了半天的时间就开发出了WMS系统的出入库模块,其中出入库部分还通过服务端命令启用了事务,支持了真正意义上的并发操作。回想起自己当年新上手Access时的状况,活字格的开发效率远超我的预期。

4.   发布成Web应用

这一步是Access开发中不涉及的。与Access设计和使用“在一起”的模式不同,使用后活字格开发的应用是一个B/S站点——这也是我最看重的一点——我还需要将其发布在服务器上才能提供给最终用户访问。我的服务器是阿里云上的ECS主机,在上面安装了活字格服务器并开启了22345端口后,我在设计器上输入IP地址等信息后,一键就将应用部署到了云端。看来活字格的生产力不止体现在开发阶段,运维方面也很给力。

5.   提交到代码库

在评估的最后,我按照帮助手册的说明,在码云上创建了Git项目,然后将活字格的工程创建为协作工程,代码上云后,多人协作和版本管理与专业的编码开发没有任何差别。这也算是我评估过程中的意外之喜吧。因为没有和其他人一起评估,也就没有深入体验这个功能。

从Access到活字格

这次技术评估,让我相信活字格已经完全可以替代Access,成为企业开发工具的升级版。随后,我就使用活字格交付了一个WMS系统。项目的成功交付,也印证了这一点。这个项目称为“WMS系统”其实有些夸张,它更像是一个模块,外挂在用友U8 ERP的数据库上。库管员在手机上做出库,系统打印出运单、随车单等单据的同时,自动生成出库单并写入U8的SQL Server数据库,再配套对应的数据管理和报表展示就是应用的全部。这是一个移动端(出库操作)+B/S网页端(管理、单据打印和报表展示)的项目,在之前我是没法承接的。有了活字格,搞定这些都变得很容易。我的实际投入甚至少于用Access开发单纯的单据管理、打印和统计报表功能,相当于移动端的费用是“净利润”。因为客户有要求,我就不展示系统的截屏了。

 

总结一下,如果你和我一样,一直做着Access的开发工作,正在纠结该如何转型,那就来了解一下火爆的低代码技术吧。也许有更好的方案,但我觉得活字格已经是一个不错的升级选项:Access能做到的,活字格都能做;Access做不到B/S和移动端,活字格也能做,而且开发效率不输于Access。值得一试哦。