我在一个外包项目里见过最惨烈的基于教程代码事故。那是层架个给某物流公司做的仓储管理系统，前任开发把业务逻辑全塞进aspx.cs的项目Page_Load里，两千多行，实战连数据库连接字符串都写死在页面里。基于教程后来客户要加个“按重量自动分仓”的层架规则，改完直接上线，项目结果所有超过30公斤的实战订单全部被分到上海仓——因为那个if判断里有个变量名拼错了，而页面文件直接引用了它。基于教程

那次事故之后，层架我接手重构，项目才真正把三层架构当回事。实战所谓三层，基于教程就是层架UI（页面）、BLL（业务逻辑）、项目DAL（数据访问）各管一摊。UI层只负责接收用户点击和显示结果，BLL层处理“重量超过30公斤该走哪个仓”这种规则，DAL层只干一件事——把数据从SQL Server里取出来或者写进去。听起来简单，但真做起来，边界划清楚才是关键。

我见过很多人把三层架构做成“伪三层”。UI层调BLL，BLL调DAL，但BLL里全是new SqlConnection、拼SQL字符串，那跟两层架构有什么区别？我自己的习惯是，DAL层只暴露方法，比如GetOrderById(int id)，返回一个Order实体。BLL层调它，然后做规则判断。实体类放在单独的Models层，三个项目互相引用，方向不能反——UI可以引用BLL和Models，BLL引用DAL和Models，DAL只引用Models。

有一次，客户要改一个库存扣减的规则：原来下单就扣库存，后来改成“支付成功才扣”。如果业务逻辑在页面里，你得翻遍所有下单相关的页面，一个个改。但在三层架构里，我只需要找到BLL层的CreateOrder()方法，把扣库存的调用从方法开头移到支付回调里，再改一下事务边界，完事。测试也简单，UI层没动，DAL层没动，只测BLL那个方法就行。

当然，三层架构不是银弹。有个小项目，总共就五个页面，后台管理，数据量一天几百条，我也硬套三层，结果光类就建了十几个，改个字段要动三个项目。后来我学乖了，先判断项目复杂度——如果页面少、逻辑简单、没有后续扩展计划，直接两层架构甚至单文件都行。但凡是业务规则有可能变、或者会有第二个客户端（比如以后要加个微信小程序）来访问同一套逻辑，三层架构的收益就立刻体现出来了。

还有个小细节，很多人忽略。三层架构里，BLL层最好别直接返回DataTable，要返回实体对象或者DTO。原因很简单：DataTable那种松散的列结构，写代码时容易拼错列名，编译期不报错，运行时才炸。实体类有强类型属性，写错了编译器直接标红。这个习惯帮我避免过无数次低级错误。

最后说个真实感受。三层架构最值钱的地方不是代码分层，而是逼着你思考“哪些东西是稳定的，哪些是会变的”。UI层永远在变——按钮位置、样式、字段展示方式，BLL层跟着业务变——规则调整、流程优化，DAL层相对稳定——表结构不大动。想清楚这个，你自然知道该把代码放哪一层。别为了分层而分层，但一旦决定用，就把边界划干净。