James Higginbotham wrote:
> Not to take too much of your precious time up, but a simple comment and
> question. When you were outlining the concept of using the web command as
> the argument to the entity bean's create(), this assumes that you don't want
> stateless session beans or other components as the primary entry point for
> creation, right?
Well, what I outlined didn't really care about whether a middle layer is
used or not. Currently I'm skipping a session facade, and am instead
using home methods, which accomplishes much of the same thing. Why split
things up unnecessarily?
But, it would be entirely possible to use session facades as a middle
step, which would be useful if you for example wanted to have a uniform
way of interacting with the EJB layer.
> I'm sure this has its uses, and for TSS it may make the
> most sense. I guess I'm accustomed to using the stateless bean wrapper
> pattern with a createXXX(), which would do the work of calling the entity
> bean's create(). This would allow me to do pre or post processing, massage
> the data a bit, or whatever else I would like to do during the creation
> process. In this case, your command pattern would still work, but it would
> be passed to the stateless bean 'manager' for pre/post processing rather
> than directly to the entity bean's create. Make sense?
Your requirements make sense, but maybe not the implementation. Much of
the massaging, and or post processing, could be done in the command. It
could also be done in the ejbCreate method itself. For example:
public void ejbCreate(CreateMyEntity command)
{
// Trim input
command.setName(command.getName().trim());
command.setEntity(this);
command.execute();
// Custom stuff
this.setTimeStamp(System.currentTimeMillis());
}
--
So, you could do both pre/post processing in the entity itself. Whether
you do it there or in the command itself, is up to you. I would probably
prefer to keep the entity code squeaky clean and do massaging in the
command, but that's mostly a matter of personal taste I think.
> Also, I am in the process of using XDoclet to construct EJB 2.0 stateless
> and entity beans for doing life's redundant tasks - user account mgmt,
> emailing, content mgmt, etc. I have seen a few sites out (like OpenSymphony
> and JCorporate) offering frameworks with packaged EJBs for doing this, but I
> don't want to use someone's framework just for some EJBs (and I've already
> chosen the frameworks I need). EJBs are distributed components, and
> therefore if they provide the API and data storage requirements I need, then
> I will use them. I plan on offering some general-purpose open source EJBs in
> this sense, unless you know of a project that is doing this already?!
I don't know of any such projects, and certainly no projects that have
been successful, and for good reasons. There are inherent problems that
make it difficult to do what you're trying to do. But that's another
discussion, and a very long one at that :-)
> In the
> process of getting up to speed with EJB 2.0 and CMR, I've constructed a
> UserAccountManager and assoc CMPs/CMRs as a starting point.
Let's say I wanted to impose access checks on modifying a user, or if I
wanted to add custom fields to an account, how would I do that with your
solution? Do you have any way to handle extensibility and integration?
How about getting user info from various backends, such as RDBMS or LDAP
or XML or..?
IMHO there are vital points missing in todays toolkit in order to allow
wide reuse of components such as those you outline. These holes will be
filled, but IMHO they're not right now.
Good luck though ;-)
/Rickard
--
Rickard Öberg
Chief Architect, TheServerSide.com
The Middleware Company
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
