Q & A
| Q1: | There is much material available on application design and architecture. Why should I use patterns? |
| A1: | Patterns are mined from concrete examples of design and architectural elements that have been used and proven in delivered systems. A pattern is only a pattern when it has been identified in multiple existing designs or architectures. As such, a pattern is more than just an opinion. |
| Q2: | What effect do J2EE patterns have on the systemic qualities of a design, such as scalability and availability? |
| A2: | Correctly applied, J2EE patterns will improve one or more of the systemic qualities of a design. As an example, consider the Value Object pattern. The primary purpose of using a Value Object between client and server is to reduce network chattiness, where a client makes repeated calls to a server to obtain a set of related data. By creating a single object to represent such data, only a single method call is required to retrieve the data. This improves the performance and scalability of the system. |
| Q3: | Can I only apply J2EE patterns to new designs? |
| A3: | No. J2EE patterns can be used to re-shape existing application code to improve its maintainability and other systemic qualities. |
| Q4: | Why do J2EE patterns tend to abstract the access to underlying databases? |
| A4: | An important part of good design is to reduce the dependencies between parts of a system. As an example, consider the use of a Session Facade to hide the underlying structure and relationships of the business data. The Session Facade interface should be business-oriented rather than data-oriented, because the Session Facade provides business services instead of raw data. Obscuring the structure of the data means that this data can be changed at a later date without requiring changes to the client. |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.