users@glassfish.java.net

RE: Re: Session beans and entity beans - which is best practice?

From: Markus Karg <karg_at_quipsy.de>
Date: Mon, 26 May 2008 11:16:30 +0200

If you need the future flexibility I would do this:

* Create the sessions that you need *now*.
* *Later* add as much additional sessions as "security views" as you like or need.

Ain't that a sufficient solution for *now* with beeing open for *future* flexibility?

Regards
Markus

-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: Montag, 26. Mai 2008 09:36
To: users_at_glassfish.dev.java.net
Subject: Re: Session beans and entity beans - which is best practice?

Thanks for answering, Markus

There are lots of entity beans. Some are used only within a specific context, but some (i.e. the UserAccess entity) is used throughout the application. I could, of course, do UserAccess operations in a CoreServicesBean or SecurityServicesBean, and use this bean whenever neccessary. For example; in the Inbox module, I've included all Inbox-related bean operations (for several entity beans used only in the Inbox module) in the InboxServicesBean.

It's when I'm now implementing a more complex security that I meet the "dilemma" of using the CoreServicesBean for these operations and the InboxServicesBean for the rest, or creating a new UserAccessServicesBean for only the UserAccess entity, since these operations will be extended to all modules.

I am therefore uncertain whether I should group similar entities in a single session bean (with the recurring possibility that what seems like a logical group TODAY, might turn out too restrictive next month), or create a session bean for each entity.

// Marius
[Message sent by forum member 'mariusw' (mariusw)]

http://forums.java.net/jive/thread.jspa?messageID=276521

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net