RE: BMP vs CMP with Orion
This can be complex as you have to indicate which relation to use. Does it
only work for simple cases?
For instance below you have three relations to the field person.name
1. one direct
2. via father
3. via mother
Table person(name, father_fk, mother_fk);
Translating to:
class person {
.
.
.
private String name
private father person
private mother person
}
Frank
On Tuesday, November 07, 2000 9:47 PM, Cory Adams [SMTP:[EMAIL PROTECTED]]
wrote:
It appears as though you can define/select any number of tables and or
fields from different tables to define what makes up the fields within an
entity bean.
Cory
At 10:12 PM 11/7/00 +0100, Frank Eggink wrote:
Hi Cory,
How do they recognize relations between tables?
Frank
On Tuesday, November 07, 2000 3:32 PM, Cory Adams
[SMTP:[EMAIL PROTECTED]] wrote:
I just received JBuilder 4 Enterprise and I will say that it does an
amazing job at EJB so far. You can connect to a datasource via JDBC and
pick your tables and keys for Entity CMP. It's amazing.
I'm still tweaking the deployment descriptors for Orion.
Man the money you can save on Orion should go toward also purchasing JB4
Enterprise. The two together could be a very cutting edge solution.
It does also have support for EJB 2.0 style descriptors Haven't tested
this yet though.
Cory
At 09:37 AM 11/7/00 +0100, Frank Eggink wrote:
I guess I'm using neither.
The clue is that, when you stick to the rules, you have to write the
minimum one panel and one table
per dataobject as all the access to the properties is done via methods and
each of those methods is
specific for the dataobjects (e.g. getName(), setName(x)). When you have a
lot of dataobjects that is
a bore.
The 'pattern' I'm using abstracts away (= marketing speak) from the clean
OO model. The generator
generates standard bean access (getProperty(index), setProperty(index, x)
and by using descriptors
for the dataobjects and its relations is it possible to generate default
screens. Something you would
most likely use reflection for when that was possible.
Using reflection has two problems:
- It does not work with Orion.
- It works only on a per object basis.
You could solve those by adding on the client side wrapper objects that
implement Just-Another-Layer.
You can use reflection for that layer and if you device you object in a
clever way (using clever naming
patterns) you -can- use reflection.
Why the complex stuff and not generating the tables and the panel. Well,
in the system I'm using I plan
to implement the option for users/systemmanager to tailor their screens.
You can do that when you
generate screen on the fly, you can't when they are already compiled.
It is a bit of an excercise but I am always strongly in favour to use as
less as possible code to build your
final system. A lot of bugs stem from silly mistakes: the less code, the
less silly mistakes. And if in the
above generator there is a silly mistake it is reproduced in a lot of
places: more chance to be discovered.
I guess the same model could be used for dynamic creation of HTML.
Frank
On Monday, November 06, 2000 11:16 AM, Cory Adams
[SMTP:[EMAIL PROTECTED]] wrote:
Are you using the command or business object pattern?
At 08:49 AM 11/6/00 +0100, Frank Eggink wrote:
I'm using Swing instead of JSP.
On Sunday, November 05, 2000 9:04 PM, Cory Adams
[SMTP:[EMAIL PROTECTED]] wrote:
Thanks for that update.
Do you or does anyone else know of the MVC (model - view - control)
pattern
used with JSP - Servlets and EJB? I have read that a single servlet
becomes that controlling mechanism to the EJBs. I wondering how
that is
done?
Cory
At 10:23 PM 11/5/00 +0100, Frank Eggink wrote:
My personal trade off was:
Why not CMP 2.0 style:
- Too scared to use it for real as it is not even officially
there ...
Why choose for CMP 1.1?
- CMP is more portable (across db's).
- Working already towards EJB2.0.
- The claim is CMP can be optimized better (I would be happy to know
more
details about that, until that time it is a bit
of a bet on a blackhorse for me).
Why choose for BMP?
- I do not know yet whether I'll run into trouble with complex and
highly
flexible queries requirements
for Query By Example forms. The requirement for extra flexibility
could
become an argument.
I would say if you can spend the time learning enough about CMP
1.1 I
would go for that as a first option. The EJB1.1
specs are even written so that you can sub class a CMP bean to
create a
BMP bean.
One of the biggest disadavantages of EJB's is the tremendous
amount of
redundant code you have to write. Add for
instance a field to a bean.
RE: BMP vs CMP with Orion
I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence
RE: BMP vs CMP with Orion
I just received JBuilder 4 Enterprise and I will say that it does an amazing job at EJB so far. You can connect to a datasource via JDBC and pick your tables and keys for Entity CMP. It's amazing. I'm still tweaking the deployment descriptors for Orion. Man the money you can save on Orion should go toward also purchasing JB4 Enterprise. The two together could be a very cutting edge solution. It does also have support for EJB 2.0 style descriptors Haven't tested this yet though. Cory At 09:37 AM 11/7/00 +0100, Frank Eggink wrote: I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of
RE: BMP vs CMP with Orion
Hi Cory, How do they recognize relations between tables? Frank On Tuesday, November 07, 2000 3:32 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: I just received JBuilder 4 Enterprise and I will say that it does an amazing job at EJB so far. You can connect to a datasource via JDBC and pick your tables and keys for Entity CMP. It's amazing. I'm still tweaking the deployment descriptors for Orion. Man the money you can save on Orion should go toward also purchasing JB4 Enterprise. The two together could be a very cutting edge solution. It does also have support for EJB 2.0 style descriptors Haven't tested this yet though. Cory At 09:37 AM 11/7/00 +0100, Frank Eggink wrote: I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms
RE: BMP vs CMP with Orion
It appears as though you can define/select any number of tables and or fields from different tables to define what makes up the fields within an entity bean. Cory At 10:12 PM 11/7/00 +0100, Frank Eggink wrote: Hi Cory, How do they recognize relations between tables? Frank On Tuesday, November 07, 2000 3:32 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: I just received JBuilder 4 Enterprise and I will say that it does an amazing job at EJB so far. You can connect to a datasource via JDBC and pick your tables and keys for Entity CMP. It's amazing. I'm still tweaking the deployment descriptors for Orion. Man the money you can save on Orion should go toward also purchasing JB4 Enterprise. The two together could be a very cutting edge solution. It does also have support for EJB 2.0 style descriptors Haven't tested this yet though. Cory At 09:37 AM 11/7/00 +0100, Frank Eggink wrote: I guess I'm using neither. The clue is that, when you stick to the rules, you have to write the minimum one panel and one table per dataobject as all the access to the properties is done via methods and each of those methods is specific for the dataobjects (e.g. getName(), setName(x)). When you have a lot of dataobjects that is a bore. The 'pattern' I'm using abstracts away (= marketing speak) from the clean OO model. The generator generates standard bean access (getProperty(index), setProperty(index, x) and by using descriptors for the dataobjects and its relations is it possible to generate default screens. Something you would most likely use reflection for when that was possible. Using reflection has two problems: - It does not work with Orion. - It works only on a per object basis. You could solve those by adding on the client side wrapper objects that implement Just-Another-Layer. You can use reflection for that layer and if you device you object in a clever way (using clever naming patterns) you -can- use reflection. Why the complex stuff and not generating the tables and the panel. Well, in the system I'm using I plan to implement the option for users/systemmanager to tailor their screens. You can do that when you generate screen on the fly, you can't when they are already compiled. It is a bit of an excercise but I am always strongly in favour to use as less as possible code to build your final system. A lot of bugs stem from silly mistakes: the less code, the less silly mistakes. And if in the above generator there is a silly mistake it is reproduced in a lot of places: more chance to be discovered. I guess the same model could be used for dynamic creation of HTML. Frank On Monday, November 06, 2000 11:16 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As
RE: BMP vs CMP with Orion
I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: BMP vs CMP with Orion
Are you using the command or business object pattern? At 08:49 AM 11/6/00 +0100, Frank Eggink wrote: I'm using Swing instead of JSP. On Sunday, November 05, 2000 9:04 PM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: BMP vs CMP with Orion
My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: BMP vs CMP with Orion
At 22:23 05.11.00 , you wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). check the archive of ejb-interest. bottom line is that the server can cache or prefetch data from resultsets that bmp doesn't allow. bmp typically results in many db accesses for finders (retrieving pks and subsequent ejbloads) where a good cmp engine just uses a few. Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. it is not an either-or decision. mix them as you like (typically simple stuff cmp, complex stuff sometimes BMP sometimes jdbc wrapped with a session bean). you don't decide to use either a hammer or a drill to build a house ;-). I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. same approach we use and we're quite happy with that too. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank regards, robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: BMP vs CMP with Orion
Thanks for that update. Do you or does anyone else know of the MVC (model - view - control) pattern used with JSP - Servlets and EJB? I have read that a single servlet becomes that controlling mechanism to the EJBs. I wondering how that is done? Cory At 10:23 PM 11/5/00 +0100, Frank Eggink wrote: My personal trade off was: Why not CMP 2.0 style: - Too scared to use it for real as it is not even officially there ... Why choose for CMP 1.1? - CMP is more portable (across db's). - Working already towards EJB2.0. - The claim is CMP can be optimized better (I would be happy to know more details about that, until that time it is a bit of a bet on a blackhorse for me). Why choose for BMP? - I do not know yet whether I'll run into trouble with complex and highly flexible queries requirements for Query By Example forms. The requirement for extra flexibility could become an argument. I would say if you can spend the time learning enough about CMP 1.1 I would go for that as a first option. The EJB1.1 specs are even written so that you can sub class a CMP bean to create a BMP bean. One of the biggest disadavantages of EJB's is the tremendous amount of redundant code you have to write. Add for instance a field to a bean. You'll have to change three files minimum and don't make mistakes as that will cost you time. This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well. What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more advanced bean generator then the standard ones. Based on a datamodel (Entity-Relation) it generates a set of beans for your application (including the remote and home interfaces and the *.xml files of course). The generated beans include the fields, the finder queries, the additional methods to retrieve related beans etc. As an additional bonus the beans include a more abstract way to access the properties (myBean.getProperty(int index)) as the client side of orion does not allow reflection. I use that to generate forms and tables on the client. The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily), makes CMP 1.1 managable and keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a notoruios mifftyper and am able to spend tons of time debug typos in 2638 lines of very closely resembling code. That problem is solved as well :-) Frank On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]] wrote: At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Kruger (-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH (-) Bruder-Knau?-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: BMP vs CMP with Orion
A Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . ok, if complexity is your main concern I wouldn't say cmp (at least 1.1) is more complex than writing jdbc code to use bmp. of course you have to learn something you don't know yet but I wouldn't accept that as a reason not to use cmp. you would lose too much just to avoid a little spec-reading and exploring orion's deployment files. it's definitely worth the effort. are you working on a real life project or is this just playing around wit the technology? if it's not the latter I would strongly reconsider using ejb2.0 as that leaves not much room for changing the server if something doesn't work with the one you're using. very risky decision if your project is going life in the not so distant future. my 2c robert Thanks, Cory regards, robert Thanks, Cory (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: BMP vs CMP with Orion
At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? regards, robert Thanks, Cory (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: BMP vs CMP with Orion
At 11:44 PM 11/3/00 +0100, Robert Krueger wrote: At 11:23 03.11.00 , you wrote: I have looked through the 2.0 spec and find the chapters regarding CMP to be daunting. It appears as though the complexity of writing my own SQL in BMP has to be balanced against learning an entire new way of managin persistence within the XML deployment descriptors which seems to be no less or perhaps even more complicated than BMP Or am I missing something with regard to CMP being easier? yes, two things: 1. your code including the queries is guaranteed to be portable between ejb servers and databases (that's the theory) 2. you cannot possibly make optimizations using BMP that the container can make using CMP why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an alternative? Hmmm. I can find even less regarding 1.1 CMP. I have the ORielly book as well as the Mastering EJB books. The 2.0 spec is what I'm using because I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or offer more functionality??? Chapters 9 and 10 are over 100 pages which have to do with CMP. The last thing I need to do is learn another query language which is what some of the 2.0 spec seemed to indicate I would need to do I also understand points 1 and 2 above but they do not address my original question of the relative complexity between BMP and CMP. Basically 1 and 2 are irrelevant to me if I can not implement CMP and can not practically compare the relative complexity between the two because I just don't understand CMP so I will keep digging through examples and utilize the post that has been helpful that somebody posted earlier today : http://www.execpc.com/~gopalan/java/entity.html . Thanks, Cory regards, robert Thanks, Cory (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
