把数据库扔在一边(转自JavaEye)

转自JavaEye,作者：yananay
详细讨论：http://www.iteye.com/topic/94867

恐怕我认识的95％的搞软件的人，在开发一个项目的时候，都会费好大力气去做一个叫做“数据库”文档的东西。

里面使用了大量的表格，文字，等等，告诉用户：你看，我已经把系统的50％设计出来了！

可是，这真的是正确的吗？如果是正确的，为什么我发现90％的情况，这个文档竟然没有被同步更新？或者直到

项目 release 阶段，才会去最后更新一次这个文档？

我终于发现了答案：项目的设计阶段，把数据库扔在一边！

到今天我们已经达到一个共识，就是数据库的操作，其实就是数据持久的操作。什么是持久？就是把一个类里需要

的数据保存到磁盘上。你可以保存到文件里，可以保存到数据库里，这都是持久。

既然如此，那我们为什么还那么着急的确定数据库是什么样子？

我们只要设计出正确类，这个类能存储我们的数据就可以了！至于如何把这个类保存到磁盘上，或者如何从磁盘上

把这个类载入到内存里，那是另一个问题了。

很多人以为这是一个大问题，事实证明，只要你的类图设计的正确，那么持久层的处理与整个系统相比，实在是一件

小事情。而且在设计阶段不去考虑数据库因素，更有助于我们清晰的根据业务来设计系统。

那么有的人又说了，那我如何做单元测试，我可是 TDD 的！

我想，正是 TDD 导致了“把数据库扔在一边”的思维方式。你完全可以把数据库的操作做成一个接口，在单元测试的

时候，使用 mock 的方式。因为在实现业务的阶段，我们只考虑我们设计的类是不是能正确地保存数据，而不在乎它

到底是怎么保存到磁盘上的。

直到你确信业务逻辑正确，那么就可以去实现那个数据库操作的接口，去做真正的持久层。当然，这个名词叫facade模式。

而持久层是使用 hibernate，还是 ibatis ，那是另外一个问题了。如果你一定要说如果在业务逻辑里也有持久层的操作怎么

办，那我只能说你的业务逻辑类设计失败了！

不要在设计初期就费尽脑汁弄数据库设计了，把系统的类图设计正确，数据库也就是持久层的操作自然水到渠成了。

 

另外，有人可能会说，你这套在java里或许挺有价值，但是Rails呢？ Agile dev with Rails 的作者可是一开始就设计了

数据库的草图。那是因为Rails的持久层实在是太容易了！Rails 里的model，其实就是业务逻辑的model，在设计的阶段，

你设计出了保存数据的类，那么这个类就可以作为model而存在，而针对这个model的逻辑就可以写在这里。

Agile dev with Rails 的作者虽然给我们画了数据库的草图，但我仍然认为他是从模型的角度去考虑问题，而不是从数据库

的角度考虑的。