Rickard,

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? 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?

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?! 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. I'm willing to
scratch this up to a learning curve if someone has done a lot of work out
there already. Seen anything posted on TSS?

Best Regards,
James

----- Original Message -----
From: "Rickard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 17, 2001 4:23 PM
Subject: Re: [Xdoclet-user] Entity BMP, EJB2.0


J. Matthew Pryor wrote:

> Care to share any further insights about your approach?


First off, eventually I'll write articles on TSS that describe the cool
new features that I'll be implementing, including the porting to XDoclet.


> Are you using xdoclet for the DAOs as well ? What about the factory
> mechanism ? Hand coded ? Any other patterns in use there


I'm not using XDoclet for DAO's right now, but I see that as the logical
next step. For the first round I want to handcode everything and do it
"the hard way". The next round, when things have stabilized, will be to
identify common patterns and automate those with XDoclet.

One of the coolest pattern I'm using right now, and which I haven't seen
anywhere else, is the use of the command pattern and the visitor pattern
in order to do entity creation.

Example:
Usually you use Data Transfer Objects (DTOs) to initialize entity beans,
i.e. your create's look like this:
public Object ejbCreate(MyEntityDTO data)
{
   this.name = data.getName();
   ...
}

If you want several ways to create an entity, then simply add more
create's for those cases, and possibly more DTO's with different subsets
of data. Also, if there are any side-effects that should happen (such as
an entity instance count increment, or creation of helper entity) then
this will be coded directly into the entity's create method.

This makes the entity much less reusable, and it will have to change
often as client needs evolve and it is being used in different ways in
conjunction with other EJB's.

The way to solve this is to use the command pattern and the visitor
pattern. Create an entity creation command base class that has setters
for the parameters you need for creation. Then add a callback method
"setEntity(MyEntityBean entity)" to this command. In the entity you now
only need *one* create method regardless of how you want to use the entity:
public void ejbCreate(CreateMyEntity command)
{
   command.setEntity(this);
   command.execute();
}
--
The command can then copy as much data as is relevant from itself to the
entity, and initialize relationships with other beans. If anything
fails, then an exception is thrown and the transactions rolls back.

This is so incredibly powerful I'm a bit surprised noone has thought of
it before :-)

Anyway, the next step is to couple it to a web framework that is command
oriented, let's say, oh, for example WebWork. Then, the commands that
are instantiated by the web framework can be used directly for the
entity creation. The code becomes very simple, and very compact. No
extra junk needed. Example execute code in an action using WebWork:
    protected String doExecute() throws Exception
    {
       try
       {
          Portal.getForums().create(this);
       } catch (javax.ejb.CreateException e)
       {
          return ERROR;
       }

       if (invalidInput())
          return ERROR;
       else
          return SUCCESS;
    }
--
So, the command just passes itself to the creation mechanism outlined
above, where it is used to initialize the new entity.

And so on and so forth :-) Was this answer what you were asking for?

/Rickard

--
Rickard Öberg
Chief Architect, TheServerSide.com
The Middleware Company


_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user


_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to