最近这几天，看这些概念看得头晕，还是这样来看待这些东东吧（找到本征），最后数据会流向到哪里？！数据库！那么其他语言所做的努力体现在更有好的呈现这些来自于数据库的数据，就像你在 dos 和 windows xp 给用户选择一样，绝大多数用户会使用更加有好的方式，而我们其他语言所做的就是这种友好，比如，你可能呈现更好样式的报表，你可能让整个交易过程更贴近生活步骤！…… 为的，最终是操作数据库中的数据！拨开浮云终见日，我们都是基于数据库在做业务上的封装，现在提出不要面向数据库，而采用面向对象的方式来建模，这难道不是避重就轻了？！
数据的最终状态是磁盘，楼主是否需要学习汇编来存储？
楼主说的对，因为你眼里只有数据。
“pye” 说数据的最终状态是磁盘，而数据库正是对磁盘读写合理的“封装”，难道你能够用其他语言对数据库做一个有效地封装？如果数据库不能满足你的需求，你当然可以自己做自己的数据库，或者采用其他的方式来存储数据，比如文本方式；正是因为在封装上有分歧，所以才导致设计上的多种方法的出现；昨天看了一些“beepbug ”的帖子，有所感触，这些设计方法，或者说为了完成软件的“工具”的使用要适当的去拿捏，就比如设计模式的使用，不要什么地方都非得套上一个啥模式，用 if .. else 怎么不好了。
存储是一回事，业务逻辑是一回事。
存储是把数据放到硬盘上，那么我想问问如何得到这些数据呢（不是指取数据，而是数据的来源）？连数据如何得到还没有想好就想着储存，到底是谁避重就轻呢？
若果你把逻辑放到数据库，好吧，等待你的是昂贵的扩展与维护。我们脱离面向数据库，是为了更好地描述领域逻辑（或者说业务逻辑），不受具体技术干扰。
你想的是如何保存数据，而我想的是，如何让客户快速得到准确的数据。记录数据？得出后用笔用纸记下来也行，保存到数据库只是其中一种较好的方式而已，你选择他，并不代表他是本质。
存储不重要么？不是，而是他是额外的需要，他保存的是我们想要的信息。当我们只需要体验逻辑，根本不需要什么信息时。那么存储就显得不是那么重要了，如某领域的科学计数器。内存是数据活动的空间，想想你word的操作，每打一个字就写一次硬盘，你每打开一次菜单，都读取硬盘上的菜单信息。或者说到游戏上，攻击时把手举到头上的某一时刻，1WHP的BOSS打剩下1血，有哪个游戏会保存这些状态呢？游戏最多就保存了攻击前后的两个状态，BOSS战胜利或者失败（有的连这些都不需要保存）。明显的，存储是为了保存受关注的离散的状态，而不是动作过程和不受关注的状态。
模式可以说是一种便于扩展的描述，目的是实现组件化。例如观察者模式，增加观察者组件，和增加ifelse哪个更容易，更易懂。
“存储”起来的目的是什么？？？考虑一下这个问题。。。
答案：还不是为了有照一日呈现出来。
没有业务，不“呈现”，管你数据保存一万年，又有个屁用。
就好比化石不被发现，不被考古学家研究，就一直在土里埋着，和普通石头有什么区别？
结论：“存储”的本质是“持久化”的手段，作用是为“以时间为x变量的不同呈现需求”所用。
“呈现”是最终目的，直接为人类服务。
[该贴被iammarine30于2011-06-02 13:51修改过]
to iammarine30：
你可能误会LZ了，LZ意思是把核心放回数据库上，并不是不呈现的意思。“操作数据库数据”就体现了LZ的观点。基本上带有领域思维的，都会反对这一观点——数据库不是数据活动的地方。
不过，LZ也有离题之嫌。
[该贴被SpeedVan于2011-06-02 14:12修改过]
我看lz的意思是要讨论设计中“谁为主，谁为辅”。
显然lz是主张“数据库设计”为中心。
我想说的是，存储归根结底是为了“呈现”，每一次的“存进去”，必然为了下一次的“取出来”。
敢问lz有生以来，是否做过“把根本不打算取出来的数据进行过存储”的工作。
如果没有，又何谈以“存储”为中心的设计。
[该贴被iammarine30于2011-06-02 14:23修改过]
楼主严重伪命题了！
软件的最终服务目标是需求，而不是服务与数据库，数据库本身也是为需求服务的。需求就是用例，流程图等等，这些来源于业务的实际操作。
所以说软件是现实的映射或者问题领域的映射，由此可见和数据库没有关系！数据库可以存在也可以不存在！
所以，楼主自己讲的“避重就轻”就是一个避重就轻的实例！
[该贴被pye于2011-06-03 13:39修改过]