Hi Ed, Thanks for your reply. I have some comments, below, and would very much appreciate further comments from you.. Also, would be happy to hear from others on this subject. Apologies to the list for this thread in JBoss instead of on EJB-INTEREST, but it was already started here. At 08:12 AM 1/24/01 +0000, you wrote: >-----Original Message----- >From: Rick Horowitz [mailto:[EMAIL PROTECTED]] >Sent: 23 January 2001 17:24 >To: jBoss >Subject: RE: [jBoss-User] HOWTO: Replacing Entity with Session bean and >ma nage the persistence > > >Hi Ed, > > > >> >in case you need to create new/update/remove existing records in db, you > >> >just use the CMP beans - call create() with your data or look it up >using > >> > >>This goes against one of the most basic patterns in EJB design - allow > >>access to your entities only via session beans. > > > >Why is this recommended (accessing entity beans only through session > >beans)? For simple update, creation or deletion of a single record in the > >database that is mapped to an EJB entity, why would I want to go through a > >session bean instead of operating directly on the entity bean from my > >client code? Going through the session bean requires extra code (an > >additional method in a session bean), > >Actually I think not doing leads to more code and greater complexity, see >below. > > > the extra overhead of two remote calls to pass the request through the > > session bean to the entity bean, and > >The session bean is on the server. Only one remote call. And as the session >bean is performing larger "lumps" of work one remote call to a session bean >can do more work. So actually this leads to fewer remote calls. Yes, true...I was actually thinking of the extra serialization overhead of passing requests/responses between session and entity beans, but I believe that can be eliminated with a JBoss option. Only downside to this, I guess, is that the semantics of EJB are not strictly adhered to, and this feature is probably not portable to all (most?) other EJB containers. > >added complexity, with no real value as far as I can see. I can understand > > >why one would want to encapsulate logic inside a session bean for use cases > > >that update/create/delete more than 1 entity within a single transaction, > >but why do the same for an operation on a single entity bean? > >Cases where the client really can just go and perform CRUD operations on an >entity are very very rare, there are always business rules to be run. EJB and distributed business apps are a new software architecture for me and I'm having a little trouble making the leap from concept (which seems reasonable enough) to real-world example. For example, if I have a website that allows customers to register themselves, creating a Customer entity in the process, why would this require business rules. Why can't the client (servlet) just invoke the CustomerEJB::create() method to get the job done. What would you imagine the biz rules doing in this case? I read RMH's EJB book a few months ago and recall that he recommends using Session Beans to manage workflow situations...his example was making a trip reservation, I believe, which included both submitting the credit card for payment and creating the reservation bean (or something like that), and doing both operations within the same session bean method and transaction for atomicity. This makes perfect sense to me, but the "create customer" example, above, does not. Can you provide further explanation please? >That's >the session bean's job. Even if there aren't to start with, going via a >session bean makes it much much easier to add it in later with the minimum >change. > >Three reasons, security, reuse, modularity and encapsulation. > >Firstly security and re-use. If I allow access directly to the CRUD methods >on my entities then it makes it very hard to control access. For example I >may allow Customers to update their address, but only under certain >circumstances. The best way to handle this, common, scenario is to not >expose the EJB entities at all so Customer's can only update the underlying >entity by going via the session beans (=business rules) they have access to. >Adding CustomerCreateNewEntity (and so on) methods to the entities I'm sure >you would agree would not be a good idea. It would overly complicate the >entity and make it harder to re-use. > >Encapsulation and modularity. Entities shouldn't really implement business >rules. They should just *manage* their data (generate value objects, handle >updates from value objects, manage persistence etc etc). After all the SAME >CRUD on the entity could trigger different actions based on the context >under which it is being performed. So either you have to have multiple >version of each CRUD method to be called under each of those circumstances >(not a good idea, and of course you have to predict everything that might be >done in the future as well, or else have to modify your entities each time). >Or you leave the entity to manage its information and add/remove overlying >session beans as necessary. > >THE most expensive and difficult part of software development is NOT writing >the code in the first place. It's maintaing, fixing bugs and adding >functionality later. So you shouldn't judge an approach based on which is >easiest to knock together from scratch. I'm curious about how you organize your session beans, in general. Do you use a session bean per entity that contains all the accessor methods (including business rules) for the associated entity? What about operations on multiple entity beans? Do you use session beans that are functionally organized, and lump all the methods for a functional area in a bean? This approach would seem to make the session beans very fluid, and the entity beans more stable. Since business process tends to change more rapidly than the underlying data structure for most companies, this approach seems to match well with the way most requirements will evolve over time. Comments? Thanks, Rick Horowitz _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED]
