这个项目源自我的一个教学示例。在2006年的的时候,我为了解释OR的基本概念,简单的约定了表和对象之间的对应关系,然后手动编写了实体对象的增删改查的代码,显然这样写出来的代码,对于每张表来说都是重复的工作,因此进一步使用CodeSmith制作了生成实体对象的模板。这样就形成了自动生成数据库应用程序中数据访问层的简单工具,并将该工具取名为MiniDac:Mini Data Access Class,迷你版的数据存取类。
在随后的一些教学案例中,尝试使用MiniDac,发现MiniDac能成功取代项目中几乎所有数据存取层的代码,而且代码量很少,理解自然也比Hibernate这样的框架直观易懂。当然,我心里清楚,MiniDac只不过是极其粗糙简陋的教学模型而已,这些教学案例的项目规模也不大,数据库中的表也就15张左右。
原本MiniDac作为一个教学的模型,并没有多少在实际开发中的应用价值。在实际开发中,我还是一直使用Hibernate这样的大家都在用的的“成熟”的框架。然后在使用中我逐步发现Hibernate这样的解决方案并不是完美的,即便在很多时候Hibernate表现很好,但是和任何事物一样,也必然存在缺陷。呵呵,这可能就是哲学上说的:事物自身一定包含有自己的对立面吧!
我们不应该重新发明轮子,至少我见过别人已经做了,而且还不错的产品,我没有必要重复来做一个。结合开发实践,我目前对Hibernate的认识是这样的:
首先:Hibernate的O-R理想没有实现。
其次:Hibernate中的功能不见得是应该由Hibernate来实现的。
再次:Hibernate封装太多。
总之,我有一种感觉是,现在有根多框架总是要号称提供多少多少强大的功能,同时强调程序员可以省去多少多少的工作,有多少多少的工作都交给框架来“自动”“智能”完成。好像有了神奇的框架,傻瓜都能成为程序员。我显然不认同这种“想把程序员当傻瓜”的框架的设计思路。事实上,现在框架满天飞,程序员比DOS时代能轻松多少呢?我认为,程序工作本身永远需要人的智力。
只有理解了我们对Hibernate的认识,才能更好的理解MiniAccess的设计思路和功能特点。MiniAccess的目标是提供一套轻量级的存取数据的工具类,MiniAccess只是单一的做一点存取数据库的工作,其他的一概不做,只是帮您省去重复的工作。它是你手边的一个工具,使用了MiniAccess后你觉得有用你就用一下,你觉得没用,你原来该怎么做还是怎么做。这一点和Hibernate之类的OR框架是截然不同的,使用了Hibernate后,他会迫使你按照它的规矩来做事,不使用任何框架时,获取你可以方便的执行存储过程更新业务数据,而现在你可能要多做一点额外的工作,以便结合使用框架的功能。
MiniAccess的特点主要包括: