-----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. >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. 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. > >Thanks for your views, Welcome. Edward -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED]
