三层架构形象理解
三层架构（Three-Tier Architecture）是软件开发中非常经典的一种设计模式。为了易懂，我们不要聊干巴巴的代码，直接把它想象成一家运转高效的餐厅。
在这家餐厅里，有三个核心角色分工明确，互不干扰，但又紧密配合：
1. 表现层 (UI层 - User Interface) =前厅服务员
职责：负责和“顾客”（用户）直接打交道。
具体工作：给顾客递菜单、记下顾客点了什么菜（接收用户输入）、把做好的菜端给顾客看（展示数据结果）。
特点：服务员绝对不会自己去炒菜。他只管“好看、服务好、沟通顺畅”。在软件中，这就是你看到的网页、App界面或各种按钮。
2. 业务逻辑层 (BLL层 - Business Logic Layer) =后厨厨师长
职责：餐厅的“核心大脑”，负责处理真正的业务规则。
具体工作：服务员把菜单递进来后，厨师长开始判断：这道菜怎么做？先放什么后放什么？（处理业务逻辑）。如果发现顾客点了一道没有的菜，或者要求“辣椒炒肉不放辣椒”，厨师长会直接把单子打回给服务员（逻辑校验）。
特点：厨师长不直接见顾客，也不亲自去冷库搬食材。他只专注“烹饪”这门手艺。在软件中，这里写满了计算公式、判断条件和核心代码。
3. 数据访问层 (DAL层 - Data Access Layer) =仓库管理员
职责：纯粹的“食材搬运工”，管理着餐厅的冷库和储物间。
具体工作：厨师长喊一声“给我拿两斤猪肉和三个土豆”，仓库管理员就赶紧去对应的冰柜里把东西找出来递给厨师长（从数据库读取数据）。如果厨师长做好了某种秘制酱料，也会交给管理员放进冰箱存起来（向数据库写入数据）。
特点：管理员不懂怎么炒菜，更见不到顾客。他只负责“拿东西”和“存东西”。在软件中，这一层专门负责用 SQL 语句跟数据库（如 MySQL, Oracle）打交道。
为什么采用三层架构：
想象一下，如果餐厅里只有一个人（单体架构），他既要点菜，又要炒菜，还得去地窖挖土豆：
太累且容易出错：人少还能应付，一旦顾客多了，他肯定手忙脚乱。
很难找人替换：这个人要是请假了，餐厅直接停业。
三层架构的好处就在于“解耦”（各司其职）：
方便换人（易维护）：如果餐厅想重新装修换个风格（更新UI界面），前厅改头换面就行，后厨的厨师和仓库完全不需要动。
专业的人做专业的事（高内聚）：如果你想换个更便宜的蔬菜供应商（更换数据库比如从 MySQL 换成 PostgreSQL），只要告诉仓库管理员就行，厨师照样炒菜，服务员照样端菜。