面向过程编程

合乎逻辑.怎么样能把事情做好了,都合乎逻辑.
有一种办法是:建模->根据Entity/Relation来确定数据库设计.
不过我建议你尽快做出来原型,可能你的leader关心的不是你现在提出的问题.

>我Oprototype，之後O，@好象和面向ο蠓催^砹
是的，反过来了，数据库是不会参与设计中的。
数据库是什么？是数据持久化，打个比喻，你在windows下编辑文本时？是否需要首先在打字时考虑字体持久化到硬盘上的技术细节？肯定不是，而是直接进入业务：打字。

那么在业务过程中：打字时，是否你每打一个字持久化一下（也就是保存一次）？我想没人这样做！那么为什么我们做企业系统时，每次客户端一个交互都要持久化一次（也就是每次request都保存数据库呢）？

所以，专注数据库技术显然过于细节。

看看DDD领域驱动设计，直至软件系统部署，数据库才被产生出来（使用Hibernate等技术）。

DDD；领域设计过程是：
领域建模--->Model/Service---->表现层、业务层和持久层同时开工，具体细节：
1.表现层负责界面离散数据和Model Mapping映射，如使用Struts
2.持久层负责将Model持久化，使用Hibernate/EJB的实体Bean技术只要做好Mapping配置即可，无需设计数据库，如果你设计数据库，就发生Model和数据库不匹配现象，两强相争，必有一伤害，哪方做出让步，一般是软件OO比较容易修改，结果不应该让步的一方作出让步，这是错误的。
3.业务层：完成Service具体实现。由于使用Ioc之类框架，使得三层解耦非常好，不互相依赖，业务层关键是应用服务层Service的实现，包括组件技术、模式应用等等，DDD在这方面讲得比较详细。

DDD领域建模其实是告诉我们业务层如何做？使用DDD。

总之，在完全面向对象中，数据库驱动设计方式已经抛弃，数据库时代已经结束，能够接受这样思维的人很少，这是一场革命，相信多年后，它被大多数人接受，至少我现在是这样做。

为什么大家抱着数据库思路不放呢？其实是和教育培训有关，数据结构和算法一直是软件教育的经典，这种培训方式培养学生使用数学思维来设计软件习惯，实际在企业软件中，软件关键是如何快速应付变化，而不是数学公式如何高深，方向就错了。

可惜大家还在数据库设计这个错误思维方向上死不悔改，所以，我想通过Jdon来及早唤醒大家（可能自不量力）。

实战DDD(Domain-Driven Design领域驱动设计)：
http://www.jdon.com/mda/ddd.html

续：如果不使用DDD，而单纯使用Hibernate或Struts这类框架，会出现什么样情况，换句话：如果不形成自己的OO分析设计思维，而霸王硬上弓，凑热闹跟着别人后面使用Struts/Hibernate这些框架，会产生什么结果？

结果是：干扰！不适应！别扭，总感觉不自然，到底哪里出问题呢？
见下面这个帖子，作者在使用Hibernate时明显感觉不适应和干扰了：

总觉得Hibernate影响设计思路

>那么为什么我们做企业系统时，每次客户端一个交互都要持久化一次（也就是每次request都保存数据库呢）？
赫赫，恐怕您也就做过web应用罢？您随便找个用delphi做过企业应用的人问问，哪有什么“每次request都保存数据库”这种事情？为什么要每次request都保存数据库？因为http是无状态的。用户通过http跟应用程序交互以后，要么找别的办法做客户端持久，要么做服务器端持久，要么就丢掉这次交互造成的状态变迁，就这么三种选择。我倒是很想请教您一下，如果不是“每次客户端一个交互都要持久化一次”，该怎么搞？您要是能在http上把这个问题解决了，估计明年的图灵奖都没得跑。

>如果不是“每次客户端一个交互都要持久化一次”，该怎么搞？
你没有在本站好好学习吧，先学习DDD，搞清楚什么是领域对象生命周期，贴文章给你：

状态对象：数据库的替代者
http://www.jdon.com/artichect/state.htm

你搞Delphi好像不错，怎么到Web没有反而忘了本，基础知识都没有了？

>先学习DDD，搞清楚什么是领域对象生命周期

sigh，哪有那么些复杂的事情。问题很显然地摆在这里：

HTTP是无状态的。用户一次交互之后，这次交互造成的影响（或者叫“状态变迁”在什么地方留存。

只有两条路可以选，要么客户端，要么服务器端。如果不是做ajax，不用数据岛，那么就是服务器端。我看你的文章讲的也是服务器端保存状态。要在服务器端保存状态，也只有两条路，要么应用程序内，要么应用程序外。要在应用程序内保存状态，你这个应用程序就别想分布，多台服务器的classloader不可能给你加载同一个Java对象。如果不想在你的Java对象里面管理用户状态，就得把用户交互的结果老老实实弄到应用程序外的持久化服务上，不管是数据库也好memcached也好，总之每次用户交互都要持久出去。你那个文章说什么“状态管理中间件”，莫非stateful session bean就不是持久化了？恕在下愚钝，我是看不出JNDI或者缓存文件跟数据库就有什么本质的区别。

彭所说是指不用每次在数据库中持久化，而是通过状态会话Bean或是实体Bean来保存状态，这些都是在内存中跑的，所以效率也会高些，等到一些步骤操作完成后，需要保存的时候才最后持久化到数据库中，这个情况就好象购物车的例子里，不是每次选个商品就要持久化到数据库中的。

> 彭所说是指不用每次在数据库中持久化，而是通过状态会话Bean或是实体Bean来保存状态，这些都是在内存中跑的，所以效率也会高些，等到一些步骤操作完成后，需要保存的时候才最后持久化到数据库中，这个情况就好象购物车的例子里，不是每次选个商品就要持久化到数据库中的。

板桥先生写了那些关于面向对象和领域建模的文章就算白写了，因为你压根就没看。为什么这么说？如果真正是领域驱动设计、模型驱动设计，你首先就要分出应用程序域和外部服务域。属于应用程序的东西，做对象建模；外部的持久服务，用repository去adapt。adapt了以后，你就不必关心这个持久服务是jndi还是数据库。如果已经是模型驱动设计了还念念不忘说“不要每次都持久到数据库”，你的隔离在哪里？你的设计分明就还在受数据库的影响么。你还说这是板桥先生的意思，岂不是诋毁板桥先生不懂模型驱动设计？

而且你这话说得实在外行。stateful session bean和entity bean在内存中保存状态？麻烦你告诉我怎么把一台服务器的内存状态复制到集群中的另一台服务器去。我一开始就说了，如果说既要在服务器保存用户操作造成的状态变迁、又要让应用程序可集群，就肯定要用外部的持久化服务。莫非你还打算诋毁板桥先生连这点常识都没有？

>要在应用程序内保存状态，你这个应用程序就别想分布，多台服务器的classloader不可能给你加载同一个Java对象。

这里我不想普及缓存概念，首先，在应用程序保存状态和是否需要分布是两个概念；其次，在应用程序保存状态通过JBossCache这样分布式缓存当然可以实现分布，象Jive3.0以后就使用了那个收费的分布式缓存（叫什么的　有些忘记）实现分布。

本课题讨论的是面向对象分析过程是否需要数据库设计，我们试图从领域建模角度讨论，而不能讲话题扩散开去，其实整个Jdon论坛自成立到现在，基本都是在讨论这个话题，所以。一旦扩散开去就涉及太多，对看贴的人也是不尊重。

schlemiel从“Http无状态”角度来看这个问题是一个新角度，其实关于领域对象的生命周期问题，在DDD中已经有很好的描述，大概在中译本87页，大家讨论起来如果有共同对话平台就容易沟通。

DDD是啥，我认为在设计过程中，有活动图，在这当中有很多的state，这些state很多是需要持久化的，这就是数据库设计的原型，而根据一些其他的数据库设计的习惯，和一些辅助的如用户权限等方面的考虑，就可以设计数据库了。 一般项目，客户或你的老板是希望有数据的设计出来的

在现代系统设计中，数据库影子基本看不见了。

大家可以查看开源软件的appFuse，在其中你都无法寻找到数据库SQL结构，甚至找不到Hibernate Mapping文件，它们都附属在Domain Model 对象中了。
https://appfuse.dev.java.net/

如果这么极端的例子无法接受，学习学习JiveJdon3，它也是一个DDD设计的案例，只是数据库使用了以前版本的，实现一个过渡衔接。

我没看过appfuse。是不是就是把持久化放到domain中去了?

把持久化放到domain中并不好，不易管理，不易测试，不易迁移