mvc设计模式中数据库持久层的设计问题讨论，敬请参与！高见给分
在我的想法中，我把系统分为四层：视图层、控制层、业务层、数据持久层。其中数据持久层模仿ejb中的entity bean，提供对表的插入、删除、更新、查询等功能，并且数据持久层的每个bean是与数据表一一对应的，对关联表的查询通过创建视图和与视图对应的数据持久层的bean来访问，控制层、业务层对数据库的访问必须经过数据持久层，数据表不创建外键，尽量不使用存储过程。
不知这种想法是否可以，敬清高手指教！
问题点数：0、回复次数：36Top
1 楼luo_wen_jie（）回复于 2003-08-01 18:01:39 得分 0
可以呀，我现在就是这么干的Top
2 楼mechiland（打铁匠[价格公道，童叟无欺]）回复于 2003-08-01 18:03:29 得分 0
你的这种想法已经有很多实现了，说白了就是O/R映射。像CMP, JDO, Hibernate都能满足你的要求。当然，你如果想自己开发一个框架那就另当别论了Top
3 楼mechiland（打铁匠[价格公道，童叟无欺]）回复于 2003-08-01 18:04:58 得分 0
你的这种想法其实就是O/R映射啦。目前有很多种实现，像CMP, JDO, hibernate等等，Top
4 楼ltz（）回复于 2003-08-01 18:08:09 得分 0
但是这么做编程的工作量会大很多，运行效率也会低一些,做小项目不会有问题，做大项目不知会不会有问题呀？Top
5 楼wizard0128（wizard）回复于 2003-08-01 21:58:52 得分 0
顶,高手啊,什么时候到这个水平啊,羡慕,
佩服各位哥哥.Top
6 楼luckyfanjian（luckyfan）回复于 2003-08-01 22:04:17 得分 0
view,controller,bo,dao分开，非常好的设计方案！可以作为范例！Top
7 楼myvoice（阿呆）回复于 2003-08-04 09:43:01 得分 0
castor JDO, Kodo JDO,Apache TorqueTop
8 楼mydj（秋水共长天一色）回复于 2003-08-04 10:14:08 得分 0
适合大项目，小项目就不必这么复杂了Top
9 楼gundam_king（东方不败）回复于 2003-08-04 13:11:42 得分 0
不错，可以借鉴，套用struts也不错，不知道楼主领悟多少
另外其实数据库的存储过程也不错，为什么不用呢？Top
10 楼ltz（）回复于 2003-08-04 13:14:17 得分 0
请大家讨论下存储过程、触发器、外键的使用问题，我觉得应尽量减少对这些技术的使用，因为使用他们会导致系统移植、维护方面的问题。但有时后又必须使用他们，因为他们的效率高，编程实现简单。请问大家的意见怎样呢？Top
11 楼JasonCao（wisewader）回复于 2003-08-04 21:42:43 得分 0
使用or类工具，如ojbTop
12 楼cxhz_cn（Eclipse Boy）回复于 2003-08-04 22:05:31 得分 0
我也是这么做的，DAO和VO用程序自动生成，但是就是某些查询要两张表关联的用自己SQL语句写或者建立一张View,为这张View建立对应的DAO和VO.用这种技术感觉不错，就是开始写DAO这块太浪费时间，现在用自动程序导出似乎节省了不少时间，但是还是有一部分特殊的SQL语句还是要自己写。
可以考虑采用Hibernate（正在学习中~~~~~~）,听说JDO现在不是很成熟.Top
13 楼justleon（蜗牛）回复于 2003-08-04 22:33:41 得分 0
使用存储过程效率好一点，DBMS不用每次都分析SQL语句，SQL是编译过的。维护也比较方便，比如有小的变动不用改程序，改一下过程中的语句就行了。
外键看情况建，有时候建了外键删不了记录挺头疼。主要看数据完整性是由程序还是由数据 库负责维护Top
14 楼Schlemiel（维特根斯坦的扇子）回复于 2003-08-04 22:59:18 得分 0
用一个O/R mapping来管理持久层，绝对不会增加编程量，只会减少整体工作量——除非你喜欢写SQL。个人而言，我很反感写SQL，对存储过程、触发器之类的东西更是深恶痛绝，所以我一定会设计一个O/R管理的持久层。Hibernate是一个不错的选择，使用还算简单，功能很强大。Top
15 楼north7703（）回复于 2003-08-05 18:31:50 得分 0
大家有没有觉得关系数据库其实和OOP是鱼和熊掌。Top
16 楼liuty2006（）回复于 2003-08-07 03:56:00 得分 0
upTop
17 楼jeffyan77（jeffyan77）回复于 2003-08-07 05:38:24 得分 0
JDBC, CMP, or JDO?
Summarize the multidimensionality of object
persistence technologies to help you make the right decision for your
enterprise application
by Dr. Wilson Cheng and Dr. Pinaki Poddar
The first three installments of this discussion
covered a range of factors you must consider in
choosing an object persistence technology for
your enterprise applications. Namely, the previous
postings discussed mapping support and domain
models of JDBC, CMP, and JDO; object query
mechanisms; transaction state management;
performance and scalability; and portability. (See
"Choose the Right Object Persistence" (Java Pro
online, July 16, 2003); "More Object Persistence
Choice Factors" (Java Pro online, July 23, 2003);
and Factor In Performance and Portability" (Java
Pro online, July 30, 2003.) In this final installment,
we'll look at one additional factor, mechanics, and
then summarize object persistence match-ups
with application types to help you make the choice
that is right for you.
Mechanics
Mechanics covers the practical aspects of demands on human and technical resources required for
application development using an object persistence service, typically called the
develop-deploy-run-test-debug cycle.
JDBC is low cost for relational applications. JDBC development is simple as long as mapping of a
domain object to a data store is straightforward and no performance optimization is required. JDBC
applications have a moderate development cycle because JDBC drivers are easy to install. No intermediate
step such as EJB compilation or JDO enhancement is needed, no separate mapping specification is
required, and JDBC applications do not require an application server.
However, JDBC's complete dependence on SQL can cause unsafe programming. SQL statements are
specified as String arguments to the JDBC API, which means a Java compiler cannot verify the correctness
of these statements. Many syntactic and semantic problems in SQL commands (such as misspelling a table
name) are thus discovered only at run time. JDBC development contradicts the type safety of object
languages for detecting errors at compilation.
CMP development is costly because domain objects must conform to Enterprise JavaBean (EJB) design.
Bean development is highly nonlinear. A bean specification is widely distributed in its home interface (how to
create it); remote interface (how to interact with it); implementation; deployment descriptor (how to configure
it); and, especially for CMP, in its mapping specification (how to map it to the data store).
All specifications must be compatible. Some specifications are verified at compilation—for example, whether
a business method in a remote interface is implemented in the bean implementation class. Others are used
only at deployment—for example, whether the mapped column name exists in the data store. An error
discovered in deployment can trigger a new develop-deploy-run-test-debug cycle. And because CMP requires
an application server, the application server usually must be restarted.
JDO is inexpensive. Of the three technologies, JDO applications offer the most development ease.
Application code is simpler because the JDO driver handles automatic persistence of new objects, mapping
to the data store, and identification of objects committed in a transaction. Effectively, a developer needs to
code only the business logic of the domain objects; the interaction of domain objects with the data store is
almost transparent to the application.
Defining the domain model with JDO is more straightforward than with CMP. A developer does not have to
specify any special interface or inherit from any class to enable the JDO driver to manage a domain object.
All that is needed is to specify the mapping configuration and run the enhancement process. Similarly,
testing can be done in an inexpensive, nonmanaged environment without an application server.
Top
18 楼jeffyan77（jeffyan77）回复于 2003-08-07 05:39:38 得分 0
Choose Your Technology
The multidimensionality of object persistence
technologies can make choosing the right one for
your enterprise application a complicated task.
Consider some generalizations about JDBC, CMP,
and JDO that can help you make a decision. We pair
the technologies with three types of enterprise
applications: RDBMS-centric applications,
application-server-centric applications, and
object-centric applications. Our pairing of
technologies to their most suitable types of
application does not imply that the given technology
is not suitable or does not work well with other types
of applications. For example, you can use JDO with
session beans to gain the advantages of JDO and at
the same time take advantage of J2EE application
server infrastructure.
JDBC is RDBMS-centric. JDBC is suitable for
RDBMS-centric applications. RDBMS-centric applications are those where the design of the domain object
model is primarily driven by relational database schema. Many applications are of this type because RDBMS is
the most common data store.
JDBC is preferred if you need to maximize RDBMS computational power, such as aggregational queries.
Because JDBC is tightly coupled with the database schema, you might prefer JDBC if application portability is
not an issue, if the schema is fairly stable, and there is no requirement to interact with non-RDBMS data stores.
JDBC is also suitable when transaction semantics are simple, primarily read-only, do not require a high degree
of configurability, and commit closure is easily identifiable, because a JDBC application has to explicitly
synchronize the states of transaction entities to the data store.
JDBC is popular for Web-based, user-view-centric applications, and reporting applications based on existing
RDBMS. These kinds of applications are primarily read-only and require rapid development. Their domain object
models are usually in close correspondence with the RDBMS schema. Finally, JDBC's lack of client caching
makes it less desirable for applications that need to scale.
CMP is application-server-centric. CMP is centered on the power of a J2EE application server.
Application-server-centric applications rely on the infrastructure services of J2EE. CMP is only one of many
J2EE services. Other features of EJB applications include load balancing across application server clusters,
declarative control of transaction semantics, deployment-time security to control access, remote access using
many different protocols, and support for messaging. You might choose to use CMP and EJBs if these general
features of application servers are of primary importance. EJB development is costly, but J2EE services can
justify the cost if business requirements demand the features of an application server. CMP object persistence
alone is not usually a sufficient reason for choosing EJB and application servers for your enterprise application.
JDO is object-centric. JDO is the technology of choice for object-centric applications. Object-centric
applications are those where the domain object model requires advanced object modeling concepts, data store
access is primarily navigational, and computational logic is expressed by behavioral Java methods of objects,
not SQL statements of an RDBMS. JDO has sophisticated object management and transaction state
management. Object-centric applications are easy to develop and highly portable despite schema or data store
technology changes. You should consider JDO if your application must work with multiple types of data stores.
Many business domains, such as telecommunication routing, financial data modeling, and VLSI design, use
graph and tree as the primary metaphor for their object models. These applications also need sophisticated
algorithms that require navigational access over a graph of interconnected objects. For example, finding routes
in a map, executing a flowchart in a rule engine, or exchanging exotic financial instruments all are
graph-and-tree problems. Unique JDO features such as persistence-by-reachability, which detects the closure
of a graph of objects, or implicit fetching of objects from a data store by navigation can be extremely useful for
such applications.
About the Authors
Dr. Wilson Cheng, vice president engineering, directs product development strategies and initiatives at Versant
Corporation; has led interdisciplinary, intercompany teams to improve cross-platform, e-business solutions at
Oracle; and was the chief architect for the object-replication project for Jasmine at Fujitsu. Cheng published
more than 20 technical articles in various international conferences and was the program chair for the sixth
annual Australian Conference on Parallel and Real-Time Systems.
Dr. Pinaki Poddar, principal software engineer for Versant Corporation, works in the area of object persistence
and J2EE integration. He designed enterprise applications for the health care and finance industries and
developed a Hindi speech recognition system in his past life. He is also a contributor to www.openadaptor.org,
an open source project for enterprise application integration. Reach Dr. Cheng at wcheng@versant.com, and
reach Dr. Poddar at ppoddar@versant.com.
Top
19 楼favourl（往事如烟）回复于 2004-03-04 17:51:13 得分 0
upTop
20 楼donghx1234（冷裂）回复于 2004-03-04 18:09:01 得分 0
这么多高手，什么时候才有出头之日啊
郁闷Top
21 楼icebluenet（冰蓝泠）回复于 2004-03-05 11:45:59 得分 0
在我看来，前端的表示层的查询，还是用传统的JDBC解决比较好，效率比较高，而且更加灵活。
删除，修改用CMP的方式。
我也不主张使用过多的存储过程，这样当你要移植系统的时候，你会恨不得你所写的一切都是SQL92。但是存储过程的执行效率确实是很让人难以放弃的。
Top
22 楼diaopeng（放飞自己）回复于 2004-03-05 12:27:17 得分 0
MVC本来就是三层，因为这已经足够了，分为四层根本就没有什么实际意义。业务层和数据持久层都是MVC中的模式层的功能，至于是用什么方法实现根本不是模式主要目的，模式只是提供一种思想和方法论，而不是实际应用，讨论这个问题根本就没有意义Top
23 楼xuu27（乐者为王(xuu27)）回复于 2004-03-05 15:13:29 得分 0
MARKTop
24 楼jiganghao（JH）回复于 2004-03-05 15:21:35 得分 0
1. Your idea, view(presentation)/control/business logic/persistence is not MVC, but 'tiered' pattern. It is not MVC cuz we dont encourage presentation tier (if you think it is V) directly access persistence tier (if you think it is M). In J2EE framework, system is split into tiers: client, presentation, business logic, persistence (or integration, the latter includes DB, legacy system, and 3rd party). MVC is mostly used at presentation tier.
2. I dont suggest using a separate control tier. For scalability/reusability/etc., you'd better not use this centralized way. For business control logic, put into business domain objects, make them autonomous -- a requirement of OOAD. For web page workflow logic, put into "C" of MVC at presentation tier.
3. For each http request in a use case, it should be converted into a command (eg. struts action) by "C" of MVC at presentation tier, the command calls a business delegate (at business logic tier), which calls a fasade (using service locator if needed). The fasade is a dispatcher, which calls corresponding Application Object or Business Object. A BO might manipulates a Data Object, which might access persistence tier by way of DAO. Method parameters and/or return values can be mapped into Transfer Object or Value Object. A tip: for every such Object (I call them XO :), try hard to make it a java bean.Top
25 楼jiganghao（JH）回复于 2004-03-05 15:23:09 得分 0
1. Your idea, view(presentation)/control/business logic/persistence is not MVC, but 'tiered' pattern. It is not MVC cuz we dont encourage presentation tier (if you think it is V) directly access persistence tier (if you think it is M). In J2EE framework, system is split into tiers: client, presentation, business logic, persistence (or integration, the latter includes DB, legacy system, and 3rd party). MVC is mostly used at presentation tier.
2. I dont suggest using a separate control tier. For scalability/reusability/etc., you'd better not use this centralized way. For business control logic, put into business domain objects, make them autonomous -- a requirement of OOAD. For web page workflow logic, put into "C" of MVC at presentation tier.
3. For each http request in a use case, it should be converted into a command (eg. struts action) by "C" of MVC at presentation tier, the command calls a business delegate (at business logic tier), which calls a fasade (using service locator if needed). The fasade is a dispatcher, which calls corresponding Application Object or Business Object. A BO might manipulates a Data Object, which might access persistence tier by way of DAO. Method parameters and/or return values can be mapped into Transfer Object or Value Object. A tip: for every such Object (I call them XO :), try hard to make it a java bean.Top
26 楼jiganghao（JH）回复于 2004-03-05 15:45:50 得分 0
sorry I posted same thing twice due to browser problem.
next part:
1. I dont recommend each bean at persistence tier maps to a db table. such 'direct' mapping will lose all benefits we get from DBMS. Your DAO is an adapter between Java objects and DB tables. extensibility, maintenance, and performance should be considered in design. J2EE core patterns, edition 2, gives some design suggestions. basically, your bean should be coarse-grained, group relavent DB tables by coherence to avoid inter-bean relations. some OR mapping tools can help.
2. DB is critical in certain applications. DB performance does matter. you can do a DB operation on millions of DB records, but seldom, if possible, on millions of java objects. pattern/framework/tool, eg. DAO, helps separate java code from DB operations, where sometimes stored procedure/trigger is the only means for acceptable performance.Top
27 楼mailguoyy（不再沉默）回复于 2004-03-05 19:46:08 得分 0
markTop
28 楼nql10（林）回复于 2004-03-05 21:17:11 得分 0
个人基本赞同楼主的想法，在适当的地方使用存储过程是有必要的！Top
29 楼01101230（叶开）回复于 2004-03-07 14:10:27 得分 0
对控制层有点意见，我觉得控制类应该出现在业务层，持久层和持久设备的交互是它自己的职责。
我现在在.net下做，参考EJB和ECC模式，我做了如下设计：
PersistentObjectHome //Only a PersistentObject Factory
{
Create(); //create in memory
GetByPK(); //get method
}
PersistentObject //abstract class ,all persistentObject inherit it
{
int ID;
State ObjectState; //enum that include {IsNew,IsModified,IsRemoved}
getField(); setField();
refresh(); //according to ObjectState ,Add/Update/Delete current object in db
}
PersistentObjectCollection
{
updateCollection();
getObjectFromCollectionByID();
refreshCollection();
......
}Top
30 楼01101230（叶开）回复于 2004-03-07 14:12:41 得分 0
数据访问代码通过配置文件，自动完成。Top
31 楼death0320（死亡金属）回复于 2004-03-08 04:40:37 得分 0
个人觉得写SQL语句也不错的。程序员学会一些数据库的知道还是很有用的。不要只会写代码，我就不喜欢什么自动生成的SQL语句，我就喜欢自己写SQL。对于存储过程怎么说呢，我感觉不错，可是大家说到移值性上，那也没办法，谁让存储过程速度快呢。Top
32 楼zkjbeyond（jigi）回复于 2004-03-08 08:55:05 得分 0
JSP设计模式
一：介绍
记得初学jsp的时候，总喜欢把他和asp,php去比较，也习惯于使用asp的开发模式去写jsp后来才发现这真是很傻的做法，其实jsp一出了来就已经用MVC模式了。下面我就简要说说jsp设计使用MVC来设计。
二：MVC介绍
MVC其实是模、视图、控制的缩写，也就是说在使用jsp时，有相应的文件去实现相应的操作
通常jsp只负责view也就是只负责显示页面。业务逻辑等有bean(ejb)去实现。下面讨论的是不使用ejb的情况下实现。如果使用ejb,ejb负责M.C通常会由servlet去实现。或者使用struts。struts的介绍你可是去http://jakarta.apache.org/struts去看。以后的文章中我会介绍。
三：设计思路
当你构建一个Application时。你必须考虑界面的问题，而界面修改是非常平常的。如果你在jsp中实现所有的操作，一旦修改界面你麻烦大了。美工不懂jsp的，你必须自己去修改无数个文件，头不要太大，而此时一般时间都很紧，使用MVC则可以减少你的一些麻烦。在设计时候jsp只负责显示页面，也就是说jsp调用Bean(Struts,servlet)传过来的数据然后显示而Bean(Struts,servlet)负责收集jsp需要的数据，用ArrayList(Arttibute)传给jsp。假如需要提交表单，一般也直接提交给Struts,servlet,处理后以后再返回处理信息。而其中相应的业务逻辑由Bean去实现。
四：Bean的设计
在我使用时候Bean通常有三类，分别在manager,entry,database目录下面。
manager下面的bean做商业逻辑
entry下的bean就是封装数据，其实就是每个数据库表对应会有一个bean。jsp得到的也全部是类。
database下的bean就是操作数据库，执行如insert,update,delete,load(查询一条记录),batchload(查询多条记录)。
他们之间的关系是entry负责封装数据，作为database的调用参数，返回结果。
manager调用database处理的结果。manager和jsp通信。jsp得到的结果从manager来， jsp需要做操作调用manager,即使是一个insert 在database存在这样的方法但在manager中你还是需要再封装一次。这样做的目的是使结构尽量简单。database只负责操作数据库。manager只做逻辑（取相应的数据）处理相应的逻辑，而entry则只把database取到的数据封装，或则把页面得到的参数封装，做为参数传给相应的Bean.
五：设计实例
下面我把留言板作为实例来讨论：
entry/Guestbook.java(留言板对象)
database/GuestbookMap.java(更新，删除，修改留言板)
manager/GuestbookManager.java(处理所有的事务)
数据表结构(postgresql)
create sequence seq_guestbook increment 1 ;
/**序列号生成器**/
create table guestbook(
id int8 default nextval('seq_guestbook'), /**主键**/
title varchar(64),/**主题**/
body text,/**内容**/
sayid int8,/**发言人**/
toid int8,/**接受人**/
saytime datetime default now(),/**留言时间**/
newflg smallint default 1/**是否查看过**/
);
Guestbook.java
=======================
import java.util.*;
public class Guestbook(){
private int id;
private String title;
private body title;
private int sayid;
private int sayid;
private Date saytime;
private short newflg;
public Guestbook(){
}
public int getId(){
return this.id;
}
public void setId(int _id){
this.id=_id;
}
........
(全是get/set方法)
}
GuestbookMap.java
==============================
import Guestbook;
public class GuestbookMap(){
public GuestbookMap(){
}
public Guestbook load(int id){
file://取到一条guestbook
}
file://sqlstr 查询条件
file://orderstr 排序条件
file://rcdbegin 记录开始
file://rcdend 记录结束
//
public ArrayList batchLoad(String sqlstr,String orderstr,int rcdbegin,int rcdend){
file://ArrayList 里面封装了Guestbook
}
public void insert(Guestbook info){
}
public void update(Guestbook info){
}
public void delete(int id){
file://取到一条guestbook
}
public int getRcdNums(String sqlstr){
file://取记录条数
}
}
GuestbookManager.java
根据需要封装需要的方法，这部分才是你要写的
上面的方式entry,database的文件可以自动生成，这个工具我已经开发了，如果需要联系我。你需要写的就是GuestbookManager里面的方法，你也许会觉得工作量比你所有的操作都在jsp中大，但是这样结构非常清晰。你还需要的就是写一个数据库连接池，你所有的数据库操作都从一个地方取，每一次都去连接数据库开销很大的。Top
33 楼zkjbeyond（jigi）回复于 2004-03-08 08:59:32 得分 0
数据层如果你设计不好的话，速度是很慢的。不要以为ejb就好，他的速度是很慢的。
我个人觉得一定要从需求入手，分析用哪种方案。
如果业务很明确，就写sql语句也可以，但oo思想，组件的可重用性。
还是从设计模式来的好。
Top
34 楼programer23（亮子）回复于 2004-03-09 08:29:45 得分 0
学习Top
35 楼Leemaasn（小鸟）回复于 2004-03-09 08:56:56 得分 0
强，果然高手。。。。友情Up。。。
Top
36 楼aaronyes（生活需要进步）回复于 2004-03-09 19:12:06 得分 0
UPTop
37 楼flyingbug（Effective Refactoring）回复于 2004-03-09 22:46:31 得分 0
mark
Top
