t********k
发帖数: 808 | 1 开发EJB有下面二种方法
1.访问数据库放在EJB里面，包括SQL语言都放在里面
2.SQL语句放在一个JavaBean里，在此JavaBean里调用EJB，
把SQL语句作为参数传给EJB
方法1好处是如果团队开发，其它人或其它应该系统要访问EJB时很方便，
不用熟悉相关的数据库细节，我只要提供他们一个JavaBean接口就行了。
但此方法有一点不是很好，业务有变化时就要修改EJB。
方法2很灵活，万一业务有所变化，部署在服务器里的EJB不用变化，
只要修改客户端的JavaBean就行了，这样不用重启服务系统。但此方法
如果别人要访问EJB时很不方便，而且要熟悉数据库结构。
我记的用EJB就是为了能让其它系统访问本系统的资源更方便，那就要用方法1吧？
别人告诉我方法2，我觉的也不错，如果系统小而且没有向其它系统提供资源的需要时
大家能不能讨论一下这二方法？给些建议，谢谢！！！ |
g*****g
发帖数: 34805 | 2 我觉得方法1是正常的吧，business logic应该在
server端，ejb里，放在客户端已经违背了3层模型的本意。
客户端有可能是web browser或者desktop application.
更多的时候我们可能只是轻微改变EJB的逻辑，比如
今天所有东西10%off，但是接口是不变的。
【在 t********k 的大作中提到】
: 开发EJB有下面二种方法
: 1.访问数据库放在EJB里面，包括SQL语言都放在里面
: 2.SQL语句放在一个JavaBean里，在此JavaBean里调用EJB，
: 把SQL语句作为参数传给EJB
: 方法1好处是如果团队开发，其它人或其它应该系统要访问EJB时很方便，
: 不用熟悉相关的数据库细节，我只要提供他们一个JavaBean接口就行了。
: 但此方法有一点不是很好，业务有变化时就要修改EJB。
: 方法2很灵活，万一业务有所变化，部署在服务器里的EJB不用变化，
: 只要修改客户端的JavaBean就行了，这样不用重启服务系统。但此方法
: 如果别人要访问EJB时很不方便，而且要熟悉数据库结构。
|
m**c
发帖数: 90 | 3
It really depends, if you are using CMP, the database access code will be
provided by EJB container, if you are using BMP, you need to implement
database access code. In most BMP cases, people will delegate database access
code to a DAO (Data Access Object) layer - to separate business logic and data
access. This can be useful if you have to use some vendor-specific SQL
statement (i.e. multiple DAO objects support a single EJB).
时
【在 g*****g 的大作中提到】
: 我觉得方法1是正常的吧，business logic应该在
: server端，ejb里，放在客户端已经违背了3层模型的本意。
: 客户端有可能是web browser或者desktop application.
: 更多的时候我们可能只是轻微改变EJB的逻辑，比如
: 今天所有东西10%off，但是接口是不变的。
|
m******t
发帖数: 2416 | 4
You need to clarify first, by "EJB", are you referring to session beans
or entity beans?
【在 t********k 的大作中提到】
: 开发EJB有下面二种方法
: 1.访问数据库放在EJB里面，包括SQL语言都放在里面
: 2.SQL语句放在一个JavaBean里，在此JavaBean里调用EJB，
: 把SQL语句作为参数传给EJB
: 方法1好处是如果团队开发，其它人或其它应该系统要访问EJB时很方便，
: 不用熟悉相关的数据库细节，我只要提供他们一个JavaBean接口就行了。
: 但此方法有一点不是很好，业务有变化时就要修改EJB。
: 方法2很灵活，万一业务有所变化，部署在服务器里的EJB不用变化，
: 只要修改客户端的JavaBean就行了，这样不用重启服务系统。但此方法
: 如果别人要访问EJB时很不方便，而且要熟悉数据库结构。
|
t****s
发帖数: 141 | 5 Only session bean and JavaBean mentioned in the first post.
【在 m******t 的大作中提到】
:
: You need to clarify first, by "EJB", are you referring to session beans
: or entity beans?
|
m**i
发帖数: 89 | 6
If you already use EJB entity beans, even BMP, why bother
to have a DAO (or JDO) layer?
【在 m**c 的大作中提到】
:
: It really depends, if you are using CMP, the database access code will be
: provided by EJB container, if you are using BMP, you need to implement
: database access code. In most BMP cases, people will delegate database access
: code to a DAO (Data Access Object) layer - to separate business logic and data
: access. This can be useful if you have to use some vendor-specific SQL
: statement (i.e. multiple DAO objects support a single EJB).
: 时
|
m******t
发帖数: 2416 | 7
I only saw "EJB" in the original post, not "session bean". Am I missing
something here?
【在 t****s 的大作中提到】
: Only session bean and JavaBean mentioned in the first post.
|
t****s
发帖数: 141 | 8 Because, business logic keeps changing all the time.
【在 m**i 的大作中提到】
:
: If you already use EJB entity beans, even BMP, why bother
: to have a DAO (or JDO) layer?
|
t****s
发帖数: 141 | 9 OK, I am wrong. CMP entity beans are excluded in the post.
【在 m******t 的大作中提到】
:
: I only saw "EJB" in the original post, not "session bean". Am I missing
: something here?
|
t********k
发帖数: 808 | 10 session bean and BMP
【在 m******t 的大作中提到】
:
: I only saw "EJB" in the original post, not "session bean". Am I missing
: something here?
|
|
|
m******t
发帖数: 2416 | 11
Well, in that case, it hardly makes any sense to pass SQL to
the BMP beans - the whole idea of using entity beans is to encapsulate
teh data access logic.
【在 t********k 的大作中提到】
: session bean and BMP
|
n*****k
发帖数: 123 | 12
I agree, if you code your SQL in JSP or serlet or with any presentaton layer
component, then why bother using EJB, the idea of EJB is to separation Data
access layer and presentaton layer.
【在 m******t 的大作中提到】
:
: Well, in that case, it hardly makes any sense to pass SQL to
: the BMP beans - the whole idea of using entity beans is to encapsulate
: teh data access logic.
|
t****s
发帖数: 141 | 13 In this case, I would recommend a good book:
Mastering EJB II
【在 n*****k 的大作中提到】
:
: I agree, if you code your SQL in JSP or serlet or with any presentaton layer
: component, then why bother using EJB, the idea of EJB is to separation Data
: access layer and presentaton layer.
|
w******t
发帖数: 1422 | 14 since you only limited to use session bean and BMP - here is what I would do:
(btw, what I say if generic, specific requirement may not apply)
-BMP: I would avoid to use BMP. Actually if I remember correctly, it's
recommended that in general, use CMP if you can. I feel like that BMP is
something for EJB1.0 time, when CMP is kind of hard to handle relative complex
relationships. In 2.0 with the addition of query language and CMR, CMP is more
powerful now.
-session bean:
do not put any SQL stateme
【在 t********k 的大作中提到】
: session bean and BMP
|
c*****a
发帖数: 15 | 15 The EJB is not only about data persistence, it is also a framework to help you
to handle security, threading, transaction management etc.
The choice 2 is actually putting DAOs in front of EJBs. The reccmmended
practice is placing them behind EJBs. The db structure still can be
encapsulated in those DAOs, not really pollutes the presentation layer.
It is a little trick to avoid restarting of application server when you change
SQLs. However I do not understand why the restarting of application ser
【在 n*****k 的大作中提到】
:
: I agree, if you code your SQL in JSP or serlet or with any presentaton layer
: component, then why bother using EJB, the idea of EJB is to separation Data
: access layer and presentaton layer.
|
