Very interesting perspective.
Though slightly unorthodox.
Sometimes I wonder whether EJB as a component model provides enough
flexibility in terms of a persistence layer and satisfying a broad spectrum
of business requirements.
hmm.....
Sandeep Dath
----- Original Message -----
From: "Gene Chuang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 1:43 PM
Subject: Re: Please comment: Using java.lang.reflect to simplify database
access
> Hi Edla,
>
>
> I'm hesitant in posting codes I developed for my company, but I'm more
than
> willing to discuss my general strategies. Our EJB architecture and
designs
> runs contrary to most others you will find; our entity beans are BMP and
> fine-grained, mapping one-to-one with each of our SQL tables (as a
matter
> of fact, I wrote a custom EJBMaker that takes a sql ddl and creates all
the
> necessary EJBHome, EJBObject and Bean classese as well as the xml dd's,
but
> that's another story! ;-))
>
> What our architecture does emphasize that's consistent with many others is
> the session-bean facade pattern; any bean client of ours hit only session
> beans, which in turn hit entity. This enlargens the transaction scope,
> allowing the bean container more "space" in doing optimization tricks like
> caching, etc...
>
> Because our entity beans are fine-grained, and are all wrapped by session
> beans, the task of writing these session beans simply to call all the
> accessor method of each entity EJBObject and all finder methods of each
> entity EJBHome can get tedious. So this is where reflection comes in: by
> having our session beans delegate to reflection-based entity proxies, we
> save a lot of time in physically coding these facades.
>
> But in order to count on reflection to do your dirty work, you need to
> adhere to strict nomenclature. For example, all our sql tables are named
> after a business object (e.g. member, node, permission), and my EJBMaker
> creates entity beans based on these names (Member, MemberKey,
getMemberName,
> etc...) In our case we also use a lot of link tables (member_node,
> member_permission, etc..), which just contain 2 columns of two foreign
keys;
> these tables are mapped to corresponding entity beans MemberNode and
> MemberPermission. Instead of physically coding a session bean that deals
> with each link entity bean separately, I used reflection with a method
like:
>
> void createLink(String functionName, long assigmentID, long targetID);
>
> where the functionName can be "Member2Node", "Node2Permission", etc...
The
> function delegates to a reflection based proxy that parses the function
> name, retrieves the corresponding EJBHomes, dynamically constructs the
> primary key instances, and invokes the correct EJBHome.create() method.
> This same technique is used for removing a link and finding a link.
>
> So as you can see, reflection, if used wisely, can save you a lot of work.
> But don't overuse it unless you know what you're doing, for it is very
> difficult to debug, and even more difficult for your fellow coworkers to
> read!
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> To: [EMAIL PROTECTED]
> Sent: 1/9/01 8:12 PM
> Subject: Re: Please comment: Using java.lang.reflect to simplify database
> access
>
> Hi Chuang,
>
> Can u explain me how to use Reflection classess in the session bean to
> reduce the code redundancy, and if possible could u send me the code of
> session bean where u used this and in what other context we can use
> this?
>
> Thanks
> Edla B. Reddy
>
> ========================================================================
> ===
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
