昨天在做公司的新项目，涉及到一些数据库的访问，我就拿着自己半吊子的水平尝试去写。突然想起之前看的视频教程里有涉及到 POJO 和 DAO 之类的东西，同事写的代码里确实也使用到了这些，我就像尝试着把他们加入项目中，以方便以后切换数据库。但是问题就来了，我该在 MVC 中的哪个部分调用 DAO 呢？是 Model 还是 Controller？我无法自己找到结论，就又上网去学习了一下。
上网一搜，豁然开朗。首先在这个问题里，我需要先明白一个词，三层架构（3-tier architecture）。即：
- 数据访问层（Data; Persisted Data）
- 业务逻辑层（Service; logic part of the application）
- 表示层（Presentation）
而 MVC 模式，是表示层的一种细化。
- 数据访问层（Data; Persisted Data）
- 业务逻辑层（Service; logic part of the application）
- 表示层（Presentation）
- Model，存储需要被显示的数据
- View，显示内容
- Controller，显示逻辑
DAO 即 Data Access Object 的缩写，他是数据访问层的一种模式。所以它不应该出现在 MVC 中的任何一个地方。举一个具体的例子，当用户点击一个网站界面上的按钮时，代码中的流程如下：
- 用户发出 HTTP 请求。
- Controller 解析请求。
- Controller 访问对应的服务（Service）。
- Service 调用对应的 DAO，DAO 返回用户所需的数据。
- Service 处理并将数据发送回 Controller。
- Controller 将数据储存至 Model 中，并调用对应的 View 。
- View 根据数据实例化，作为 HTTP 应答返回给用户。
看完我感觉自己之前学了个寂寞。这次才明白这些各种层之间的逻辑是什么。不过我也不应该生搬硬套，这个三层架构很明显是对应“客户端 – 服务器”的软件模式设计的，在 Web 开发中效果很棒，但是对于完全本地运行的桌面软件，我认为将服务层与Controller集成在一起也未尝不可。毕竟一般来说，这几层解耦不解耦没区别，都是我一个人写。先不说找个大佬带我写，老板连小弟都不给我找一个，过分。
这次对三层架构的了解让我收获非常大。看完觉得自己写代码更牛逼了，高兴的写了大几百行。但是也越来越想把之前的项目重写一下了，真的越来越难以修改了，确实是有不少缺陷。