This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I have a question about using design patterns, I noticed in Chapter 9 in Humprey Shell's book, Design patterns was not much used, even simple one's like delegate, Transfer Object, Value List...etc. I noticed dependency injection was mentioned in sequence diagram.
1. Is it not required to use delegate or other patterns in UML diagrams, and we just need to mention in note that the communication between controller and SLSB is using delegate. I read your & others suggestion, that do not depict the design pattern if it involves multiple classes, just mention that this pattern is used. Other than note, where can the core design pattern be used in the required diagrams.
2. And how to justify the usage design pattern if it is not depicted in UML diagrams.
3. I noticed in chapter 9, there is no separate persistence layer bean as such, both business and persistence logic is present in same EJB, even though it calls JPA's Entity Manager. I was thinking it is a best practice keep the business logic and persistence logic in 2 separate layers.
4. In in the chapter 9 example, User class which can be a bidder or Seller is not a entity in the system. All the system has User and its derived classes as entities. Is there a reason they are not specified as entity in the chapter 9 example.
5. In the Chapter 9 class diagram, some user classes like Currency, Color, Density, Durability....etc are not present any where. Is it ok to similar kind of classes, since it reduces the number of parameters in the method calls.
6. I read lot of posts abt not modifying domain model, for my assignment factory homes, I wanted to add a parent class Component which all base house components will extend. Is adding this kind of class is also big no-no. If any of you have done this kind of generalizing existing domains, please share your thoughts.
7. In factory homes assignment, I noticed the multiplicity for House and Wall is given as 1..* in the middle and in similar fashion multiplicity for Wall and Aperture is given as 1..* in the middle.Logically it looks like 1 house can have 1 or more walls and One wall can have 1 or more aperture, is this assumption valid.
1) Some submissions use more patterns than others. I would be surprised to see no patterns used. Some patterns are part of a framework though.
3) The JPA layer/entities are the persistence layer. The stateless beans are the business logic in chapter 9.
4/5) Odd. I've added this to the "list of things in Cade/Sheil that people should take note of"http://www.coderanch.com/how-to/java/CadeSheilSceaFaq. Good find! I agree with you that you shouldn't reference classes that don't exist anywhere.
6) I added a parent class. That is fine (and a technical detail). They mean not to change the spirit of the design.
Joined: Apr 11, 2005
Thank you very much Jeanne.
Joined: Apr 11, 2005
Sorry about asking too many questions.
1) Should the uml diagrams be converted to black and white when we submit it. I am using Start UML. Is it ok to submit with default color.
2) Is it recommended for a Managed Bean to make use of Multiple Stateless session bean.