From: Rickard <ri...@mi...> - 2001-12-17 22:43:43
|
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?=20 Well, what I outlined didn't really care about whether a middle layer is=20 used or not. Currently I'm skipping a session facade, and am instead=20 using home methods, which accomplishes much of the same thing. Why split=20 things up unnecessarily? But, it would be entirely possible to use session facades as a middle=20 step, which would be useful if you for example wanted to have a uniform=20 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 enti= ty > bean's create(). This would allow me to do pre or post processing, mass= age > 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 wo= uld > be passed to the stateless bean 'manager' for pre/post processing rathe= r > than directly to the entity bean's create. Make sense? Your requirements make sense, but maybe not the implementation. Much of=20 the massaging, and or post processing, could be done in the command. It=20 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=20 you do it there or in the command itself, is up to you. I would probably=20 prefer to keep the entity code squeaky clean and do massaging in the=20 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 statele= ss > and entity beans for doing life's redundant tasks - user account mgmt, > emailing, content mgmt, etc. I have seen a few sites out (like OpenSymp= hony > 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 alre= ady > 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 EJ= Bs in > this sense, unless you know of a project that is doing this already?!=20 I don't know of any such projects, and certainly no projects that have=20 been successful, and for good reasons. There are inherent problems that=20 make it difficult to do what you're trying to do. But that's another=20 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.=20 Let's say I wanted to impose access checks on modifying a user, or if I=20 wanted to add custom fields to an account, how would I do that with your=20 solution? Do you have any way to handle extensibility and integration?=20 How about getting user info from various backends, such as RDBMS or LDAP=20 or XML or..? IMHO there are vital points missing in todays toolkit in order to allow=20 wide reuse of components such as those you outline. These holes will be=20 filled, but IMHO they're not right now. Good luck though ;-) /Rickard --=20 Rickard =D6berg Chief Architect, TheServerSide.com The Middleware Company |