我是一名企业软件的老兵，曾经用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替代品的过程中，我给自己制定了一套标准，期望能选出一个更专业的平台，用的技术一定要是主流的，不能再走从入门到放弃的老路。这套标准的核心是以下四点：
- B/S架构，支持在浏览器上使用，能支持移动端
- 能直接设计和操作数据库，有足够的可控性
- 开发效率不能比Access低，做复杂逻辑时使用主流的语言，可以能接受放弃VB
- 现有的Access数据要能复用，简化导入流程
此外，还有一个“加分项”：协同开发。Access不支持协同开发，我之前做的很多项目都是“一个人的战斗”，做起来很累，而且因为没有人可以查漏补缺，失败率也比较高。我希望新的功能能够支持团队开发，即使一些复杂项目，也可以快速搞定。
综合考虑厂商的知名度、官网的介绍内容，我选择了5款产品进行深度了解，最终结果如下表，也许不全面，见谅。
基于这些信息，我的初评如下，供大家参考。
- PowerApps：微软官方推出的Access Web应用替代品。产品功能全面，如果不是因为不支持私有化部署（绑定Azure云服务），而且不支持导入现有Access数据库，我也许会将其作为首选。
- 活字格：拿奖无数的产品，中软协的行业报告都是和这家联合推出的。产品的设计思路和编程语言选择上和PowerApps接近，做出来的系统是标准的前后端分离架构，每一层都支持编程扩展，看着很专业，学习曲线可能比较陡。与PowerApps相比，活字格支持私有化部署，还支持从Access文件导入，优势很突出。
- iVX5：之前叫iH5，有十几年的历史，在H5页面设计器领域很出名。iVX5偏重于做移动端应用，开放性偏差，自己弄了一套“编程语言”，和主流做法的差异较大。大约应该更适合业务人员拿去做一些简单场景的小应用，比如做个问卷调查啥的，很难搞定ERP甚至MES这种复杂项目。
- 宜搭：阿里巴巴的开发工具，自带光环。产品整体上偏向于toC，不支持操作数据库，开放性比iVX5还差一些。和iVX5类似，宜搭的应用场景也比较有限。
- 魔方网表：这个产品在很多互联网社区上做宣传，是最早出现在我面前的低代码产品。我一开始对其寄以厚望，然而期望越高失望越大。B/S页面粗糙且不能自定义，不支持操作数据库，没有编程接口。我感觉这款软件更像是Excel，与“开发工具”的格格不入。
经过初评，活字格和我的需求匹配程度最高，顺利进入试用评估环节。好在活字格支持免费试用，而且还有负责技术支持的小姐姐帮我远程解决问题，给我的评估工作带来了不小的便利。顺便提一句，小姐姐的声音好听，技术能力也非常强，绝不是花瓶，应该有很多年的项目开发经验。
面向实战的技术评估
为了确保活字格真的能担起替代Access的大任，我决定花几天时间，去学习如何用活字格开发出WMS系统中的出库功能，在开发过程中评估产品功能。之所以选择这个功能，是因为我最近用Access连续做了几个库管相关的项目，对需求场景的印象也最为深刻。
正式动手评估之前，我看了几部活字格的入门视频教程，了解到活字格分为设计器和服务器两部分。设计器和服务器，就像Visual Studio和IIS的关系。我使用设计器开发应用，然后发布到服务器上，最终用户拿浏览器访问就可以了。
设计数据模型
使用Access开发过应用的人都知道，做系统的第一步是设计表结构，我想用活字格也不例外。打开活字格设计器的一瞬间，我感觉这就像是Excel和Access的合体，数据表的设计方式与Access类似，可以在同一个页面上设计表结构、修改数据；甚至能在表的设计页面上，直接通过关联字段设置外键关系，而不需要打开关系视图。
虽然活字格支持使用外部数据库，比如SQL Server和MySQL，但是我这次的重点是对活字格进行评估，所以直接用了内置的数据库。10分钟不到的时间，本次技术验证用的表和关系就创建完成了，轻车熟路。
设计页面布局
在设计页面的时候，活字格的体验方式更像是Excel，在格子上画出页面元素，然后把表中的字段绑定到页面上就可以实现数据的展示和修改。我很难准确地形容三两下就拖拽出一个页面，点击运行按钮后，和设计器中一模一样的Web页面展现在眼前的感受，非常的震撼。这不就是我最想要的B/S系统吗，得来全不费工夫嘛。
趁热打铁，我在一个小时内就画出了技术验证所需的全部页面。与Access不同的是，窗体、查询和报表在活字格中统一成了“页面”：我在页面上放和表里字段对应的输入框，就成了窗体；放一个表格，拖上对应的字段，就变成了查询；再放一些图表，向Excel一样配置数据源后，就有了报表。虽然要花一些功夫来做这些页面，但是设计体验非常顺畅，也很灵活。有了格子线的参考，我很容易就做出了整齐美观的界面，比布局视图要方便很多。除了页面布局，在页面上还能直接使用Excel的公式进行逻辑判断和简单的数据处理，功能非常强大。
实现业务逻辑
在用Access做开发时，布局工作完成后，我就会切换到设计视图，为按钮开发对应的事件。Access的事件对应了活字格中的命令。活字格内置了很多命令，有些在页面上运行，比如页面跳转、简单的数据表增删改查等，有些在服务端运行，比如有事务性要求的数据处理（终于可以支持真正的并发了）。配合上Excel公式，做页面跳转、数据过滤、逻辑判断和数据处理等操作都很便利。按照教学视频中讲的，命令是活字格最核心的功能，编程接口也是基于命令机制扩展出来的。直到最近交付了第一个应用，我对活字格内置的命令还没有完全吃透，大半的命令都没有用过。慢慢来吧，技多不压身。
下面是我整理的Access和活字格的重要概念对照表。有了这张表，我相信你也可以和我一样，快速上手活字格了。
参考了活字格内置的模板，我大约用了半天的时间就开发出了WMS系统的出入库模块，其中出入库部分还通过服务端命令启用了事务，支持了真正意义上的并发操作。回想起自己当年新上手Access时的状况，活字格的开发效率远超我的预期。
发布成Web应用
这一步是Access开发中不涉及的。与Access设计和使用“在一起”的模式不同，使用后活字格开发的应用是一个B/S站点——这也是我最看重的一点——我还需要将其发布在服务器上才能提供给最终用户访问。我的服务器是阿里云上的ECS主机，在上面安装了活字格服务器并开启了22345端口后，我在设计器上输入IP地址等信息后，一键就将应用部署到了云端。看来活字格的生产力不止体现在开发阶段，运维方面也很给力。
提交到代码库
在评估的最后，我按照帮助手册的说明，在码云上创建了Git项目，然后将活字格的工程创建为协作工程，代码上云后，多人协作和版本管理与专业的编码开发没有任何差别。这也算是我评估过程中的意外之喜吧。因为没有和其他人一起评估，也就没有深入体验这个功能。
从Access到活字格
这次技术评估，让我相信活字格已经完全可以替代Access，成为企业开发工具的升级版。随后，我就使用活字格交付了一个WMS系统。项目的成功交付，也印证了这一点。这个项目称为“WMS系统”其实有些夸张，它更像是一个模块，外挂在用友U8 ERP的数据库上。库管员在手机上做出库，系统打印出运单、随车单等单据的同时，自动生成出库单并写入U8的SQL Server数据库，再配套对应的数据管理和报表展示就是应用的全部。这是一个移动端（出库操作）+B/S网页端（管理、单据打印和报表展示）的项目，在之前我是没法承接的。有了活字格，搞定这些都变得很容易。我的实际投入甚至少于用Access开发单纯的单据管理、打印和统计报表功能，相当于移动端的费用是“净利润”。因为客户有要求，我就不展示系统的截屏了，放一个网站搜到的库管PDA，我做的B/S系统就是在这样的设备上运行。
总结一下，如果你和我一样，一直做着Access的开发工作，正在纠结该如何转型，那就来了解一下火爆的低代码技术吧。也许有更好的方案，但我觉得活字格已经是一个不错的升级选项：Access能做到的，活字格都能做；Access做不到B/S和移动端，活字格也能做，而且开发效率不输于Access。值得一试哦。
