(观前提醒：这是一篇日常学习过程中的一次对问题的思考探索与总结，我突发奇想尝试把它记录下来作为学计算机的大学生活片段的一个展示。)
且本文内容及其思考并不能代表全体计算机学生的生活状态，
且本文内容可能存在种种问题，不确保其严谨性和正确性
一.故事的起源
《JAVA上机实验四》实验报告 片段截图
又出现了一个新的可能从未听过的名词
想必懂得都懂
于是我索性以此为主题
(真的并不是我找不到其他主题的了)
向你们分享这个惨淡的学习记录
二.相关信息
DAO(Data Access Object) 数据访问对象是一个面向对象的数据库接口，它显露了 Microsoft Jet 数据库引擎(由 Microsoft Access 所使用)，并允许 Visual Basic 开发者通过 ODBC 像直接连接到其他数据库一样，直接连接到 Access 表。DAO 最适用于单系统应用程序或小范围本地分布使用。
“这么简单，大家一定都会了吧”
——————咳咳——————
由于可能存在的混字数的嫌疑
我索性在这里直接与大家分享
1.核心
是一种应用程序编程接口(API)
在业务逻辑与数据库资源中间与数据库打交道
(在MVC中属于M的一环)
主要由以下五部分组成
1.数据库连接类：连接数据库并获取连接对象
2.VO实体类：包含属性和表中字段完全对应的类
3.DAO接口：提供了用户所有的操作方法(就如老师给学生提供一些学习方法)
4.DAO实现类：实现DAO中所有的方法(就如老师给提供的方法看你如何去完成)
5.DAO工厂类：为程序提供方法，如果要替换DAO实现类，只需要修改该Dao工厂类中的方法代码
(图片来源于网络)
2.好处
1)数据存储逻辑的分离：一方面避免业务代码中混杂的JDBC代码，另一方面，数据访问接口与数据访问实现相分离，这样精通数据库的人可以根据接口专注于数据库访问的最优化实现，而精通业务的人可以专注于业务逻辑编码。
2)数据访问底层实现的分离：DAO模式将数据访问分为抽象层和实现层，分离了数据使用和数据访问的底层实现细节。这样可以在保持上层结构不变的情况下，通过更改底层实现来修改数据访问的机制，比如只要通过修改数据访问层实现，我们就可以部署在不同数据库平台上。
3)资源管理和调度的分离：数据访问逻辑从业务逻辑中脱离开来，使数据访问层实现统一的资源调度，通过数据库连接池和各种缓存机制的使用，可以保持上层系统不变的情况下来提高系统性能。
4)数据抽象：通过对底层数据的封装，开发人员可以使用面向对象思想对数据进行操作。比如通过调用方法获取数据比通过SQL语句访问数据库获取数据，在代码上更易于理解，清晰，对日后维护带来便利。
三.上机指南
在实验三中，我们已经学会了(并不)利用JDBC实现数据库的连接，但是在这里对于数据库增删改查时必然不能向之前那样简单草率。
所以这里针对于实验四而言，我们可以晓得的是：
VO实体类体现的是设计怎样的数据库
DAO接口与实现类则体现实现模拟挂号的方法
试想实验四的实现过程可能大概如下：
————————————
数据库连接类实现与建立好的数据库连接
VO类体现数据库中的属性与表及相关方法
利用数据库连接类与VO类实现DAO接口及方法实现
建立DAO工厂类/测试类利用DAO接口方法实现程序功能
————————————
当然由于本身其实实验四的规模程度有限，在设计实现代码时不必达到多人协作、数据库业务逻辑分离的地步。上机实验时也不一定非要完全分离DAO的五大部分。
这一定程度上限制了我们对DAO的理解。(起码对我来说，真正想要理解它，还需要更多时间精力的投入(这也意味着)
或许你用自己的方法同样能实现产品功能，但是或许这个过程中对思想套路开发规范的学习比成果如何更重要。
(有图为证)
四.杂谈
在群里分享了这一篇文章。
其实跟师兄交流时也涉及到了这个问题。
“同样的问题 思考的深度和效率
这是没受过专业训练的人
比不了的”
那么如果想要在非科班的竞速式编程培训的其他人面前脱颖而出，我们或许其实需要的是对一些或许看起来不重要的知识的重视。而其实同样值得在意的是，要真正走到“思想方法影响效率”的那一步之前，我们总归还是要把基础一遍又一遍的打好。(因为事实上，好像很多时候我们是被难倒在了代码的面前。)
“懂得都懂”
但说白了其实，无论学习什么，我们最重要的仍然是晓得
我们到底要做什么？
我们为什么而卷？
我们又要卷向何方？
—————————————————————————
在这里希望大家能不忘初心，继续前行！
1
END
1