Access 怎么做前后端分离？用 Web API 读写 SQL Server
Access 怎么做前后端分离？用 Web API 读写 SQL Server
摘要： Access 不使用链接表，也能借助 Web API 完成客户资料的查询和保存；本文记录一个已经实际跑通的客户管理 Demo。access开发|access培训|access框架|请添加edonsoft。
Hi，大家好！
上一篇写了不用链接表访问 SQL Server，主要讲 DAO 和 ADO。后来有人继续问：如果 Access 不直接连接后台，还有没有别的做法？
有，就是在 Access 和 SQL Server 中间增加一层 Web API。
这次我没有拿订单或商品做一个脱离实际的示例，而是直接用了测试库中的客户资料表。Access 端做了一个非绑定客户窗体，可以查询客户、打开客户详情、新增客户和修改客户。服务端项目和 Access 演示库也都实际运行过。
为什么要多加一层
链接表的优点是开发快。表一链接，绑定窗体和查询都能继续使用。局域网里只有几个人使用时，这种方式很实用，我也不会为了追求新架构而强行改造。
问题通常出现在使用范围扩大以后。比如程序需要在公司外使用，同一套客户资料还要给网页或其他系统调用，或者保存客户时必须统一检查业务规则。这时让每个客户端各自处理，后面会越来越难维护。
加上 Web API 以后，Access 仍然负责窗体、报表和用户操作，中间程序负责读取和保存数据。以后后台字段或保存规则调整，主要修改中间程序，Access 窗体不一定要跟着大改。
这次 Demo 做了什么
客户资料包括客户编码、客户名称、简称、电话、地址、备注、创建信息、修改信息和启用状态。主键由后台自动生成。
中间程序提供四项功能：
按关键字查询客户列表。
根据客户编号读取完整资料。
新增一条客户资料并返回编号。
保存已有客户的修改结果。
查询时，关键字会同时匹配客户编码、客户名称和简称。每次只取前 200 条，避免窗体打开时一次加载太多数据。数据量继续增加时，可以再补充分页。
新增和修改时，中间程序会再次检查客户编码和字段长度。这里不能只依赖 Access 窗体检查，因为将来其他程序也可能调用同一套功能。规则放在一处，结果才不会因客户端不同而变化。
Access 端怎么配合
Access 使用一个标准模块集中处理数据交换。窗体模块不用关心底层细节，只负责调用查询、读取、新增和修改四个过程。
客户维护窗体使用下面这些控件：
一个搜索框和一个查询按钮。
一个客户列表框。
客户编码、名称、简称、电话、地址和备注输入框。
一个启用状态复选框。
新增和保存按钮。
窗体打开时先加载客户列表。列表中显示客户编码、客户名称、电话和启用状态，主键放在隐藏列中。
输入关键字后点击查询，Access 重新取得符合条件的客户。双击某一行，再读取这位客户的完整资料，显示在右侧编辑区。
点击新增按钮时，窗体清空当前内容。点击保存时，窗体根据隐藏主键判断当前是新增还是修改。保存成功后重新加载列表，用户可以马上看到结果。
这里有两个小细节。
第一，后台返回的空值要先转换，再放进文本框或列表框，否则 VBA 很容易在类型转换时报错。
第二，客户名称中如果有英文分号，加入值列表前要先替换。Access 的值列表本身使用分号分列，不处理就会造成列错位。
实际测试结果
我在本机完成了服务端编译、客户列表查询、单条客户读取、新增客户、修改客户和修改后回读。
随后又用 Access VBA 完整执行了一遍查询、新增和修改。测试记录在验证完成后已经清理，原来的两条客户资料没有被改动。
完整项目中保留了服务端工程、Access 公共模块、窗体事件代码和可直接打开的演示数据库。公众号正文不再粘贴大段源码，需要完整代码的朋友可以通过文末方式联系我。
什么时候值得这样做
如果 Access 和 SQL Server 都在同一局域网，使用人数不多，现有链接表或 DAO、ADO 已经稳定运行，没有必要仅仅为了“前后端分离”几个字就重做。
但当 Access 需要在不同地点使用，同一套业务还要提供给网页或其他程序，或者保存规则必须集中管理时，中间增加 Web API 就比较合适。
这套做法的代价也很明确：项目中多了一项服务，需要单独发布和维护。小项目不一定划算，到了多客户端、多地点使用的阶段，它的价值才会体现出来。
如果你正在考虑把现有 Access 系统改成这种结构，欢迎公众号后台留言，我看到了会回。
技术培训
定制开发
技术支持
联系方式：