把数据库扔在一边！(请直接下载我最后回复中的详细文档和源代码吧)

恐怕我认识的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 的作者虽然给我们画了数据库的草图，但我仍然认为他是从模型的角度去考虑问题，而不是从数据库

的角度考虑的。

模型本身不灵活 比数据库还死

建议看看spring sample 的 jpetstore，会有点感触的。

我现在的方法比spring灵活多了

把数据库先放一边我同意 但这是有条件的 如果使用sql和关系数据库这么做会死的很惨

类变一变不会对webapp速度造成太大影响 但是混乱的糟糕的数据库设计可以彻底毁掉项目

同意楼主。

我认为数据库是为了程序服务的。

如果一开始就设计好数据库，那不是要牵着程序的鼻子走？

个人以为，那些抱着盗版POWER DESIGNER不放的开发者，还停留在起步阶段。

对于那些以OO思想设计系统的人，我很佩服。

可能每个人的经历不同吧，我看到更多的是混乱的糟糕的领域对象设计彻底毁掉项目

你还是没有转换过来思想，使用SQL也只是持久层的一种方式，对不？
就是算你把数据保存到文件上，那也是持久层，对吧？

既然如此，那么如何实现这个持久层和你的业务逻辑有什么关系呢？

其实以前我也觉得spring的sample写的太麻烦，直接去调用数据库的操作不好？
不过我现在才总算明白spring的例子为什么那么写。


这只能说设计方式还是有问题了。

数据库扔一边？等你系统上线发现速度狂慢的时候怎么办？

及早发布，频繁发布
及早测试，频繁测试

spring狂热派

多说几句吧 我现在的开发方式就是不考虑数据库的 而且模型也不考虑

当有具体需求的时候就先实现它 然后再集成到系统中。

我更关心系统的结合方式和数据的标准格式 比如是用post soap还是rest 数据格式是用自定义的xml还是atom rss

仅依靠spring摆脱不了关系数据库的枷锁 系统的灵活性也是有限的