Web三层架构

凌晨两点，架构我盯着屏幕上那个500错误，架构数据库连接池爆了。架构这不是架构第一次了——上周刚上线的新功能，用户一多就出问题。架构后来我把代码翻了个底朝天，架构才发现问题出在业务逻辑里直接写了SQL查询，架构还顺手把数据库连接敞着没关。架构这让我想起十年前第一次接触三层架构时，架构师傅说的架构那句话：“分层不是为了好看，是架构为了让你半夜少接几个电话。”

三层架构说白了就三块：表现层、架构业务层、架构数据层。架构表现层管用户看到什么，架构按钮、表单、页面跳转；业务层管规则，比如“满100减20”这种逻辑；数据层管存取，跟MySQL或Oracle打交道。关键规则是——层与层之间只能单向依赖，表现层调业务层，业务层调数据层，谁也不能越级。

我见过最典型的反面教材，是某个外包项目。程序员图省事，直接在JSP页面里写JDBC代码，页面加载时连数据库、查数据、拼HTML。刚开始跑得挺欢，两个月后需求变了一次——要加个新的折扣规则，结果改一个页面要动三处SQL，改完另一处报表又出错了。最后整个团队花了两周重构，才把那些纠缠不清的代码拆开。这事儿给我留下的印象太深了：分层带来的最大好处不是性能，而是“可替换性”和“可维护性”。

表现层换起来最直观。以前用JSP做页面，后来换成了Vue或React，只要接口不变，业务层根本不用动。数据层也一样，从MySQL迁到PostgreSQL，改改连接配置和查询方言，业务逻辑里的代码几乎原封不动。这种“插拔感”在日常开发里太重要了——技术更新迭代那么快，谁能保证自己用的框架三年后还主流？

但分层也有代价。最明显的是性能损耗——一次请求要经过三层方法调用，每层都要做参数校验、对象转换，比直接连数据库多出几十毫秒。另一个问题是代码量膨胀，每个简单功能都要写三个类、五个接口，刚入行的同事常抱怨“绕来绕去”。可我看过那些不分层的项目，后期维护成本高得吓人——一个bug牵连全局，改一行代码要重新测试整个模块，那种痛苦比多写几个类难受多了。

实际开发里，我习惯给每层定个“脾气”。业务层里绝不放SQL语句，数据层里绝不放if-else规则判断。表现层只做展示和收集参数，连数据校验都尽量交给业务层处理。同事问我为什么这么较真，我说你试试看——当产品经理半夜打电话说“把折扣规则从满100改成满150”，你只需要打开业务层那个类，改一个数字，然后睡觉，那种踏实感是钱买不来的。

当然，三层架构不是银弹。小项目、原型验证、内部工具，硬套三层反而拖慢速度。我做过一个爬虫脚本，就一个文件搞定，连数据库都没用，分个屁的层。但只要是面向用户、要长期迭代的系统，哪怕一开始只有两三个页面，我也建议先按三层结构搭骨架——因为需求这东西，永远会变，而且总是在你最不想改的时候变。

说到底，三层架构的核心理念就一句话：让变化只发生在该发生的那一层。你不需要记住什么理论框架，只要记住——下次半夜被叫起来修bug时，如果能迅速定位到是页面问题、逻辑问题还是数据库问题，那你的架构就算立住了。