Quick Recap: Chapters 51 to 58

Let us quickly review whatever we learnt about Design Patterns in the previous few chapters

• A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution
• There are 5 design patterns in the SCWCD Exam:
     o Value Object Pattern
     o Data Access Object Pattern
     o Business Delegate Pattern
     o Model View Controller Pattern &
     o Front Controller Pattern
• The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency
• The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this
• The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other
• The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller).
• The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource.

The Key Terms we learnt in the previous few chapters are:

• Design Patterns
• Model-View-Controller
• Value Object
• Data Access Object
• Front Controller
• Business Delegate

Previous Chapter: Chapter 58 - Other Design Patterns

Next Chapter: Self Test - Chapters 51 to 58

Chapter 58: Design Patterns Beyond the SCWCD Exam

Design Patterns is a very big subject and we could just go on and on and on about them. The good news is that, the SCWCD exam covers only 5 design patterns which we have already seen. So, if you want you can conveniently ignore this chapter. But, I strongly urge you to read it, not to memorize but to improve your understanding of design patterns.

So, lets get started!!!

Other Design Patterns:

There are numerous other design patterns that are in use in the programming world. They are categorized into various types based on their purpose. Let us take a look at their categories and names.

1. Architectural Patterns
      a. Decorator Pattern
      b. Front Controller
      c. Model View Controller
2. Advanced Architectural Patterns
      a. Composite View Pattern
      b. Service to Worker Pattern
      c. View Helper Pattern
3. Scalability Patterns
      a. Asynchronous Page Pattern
      b. Caching Filter Pattern
      c. Resource Pool Pattern
4. Business Tier Patterns
      a. Entity Facade Pattern
5. Data Transfer Patterns
      a. Data Transfer Hash Pattern
      b. Data Transfer Object (DTO) Pattern
      c. Row Set DTO Pattern
6. Database Patterns
      a. DAO Factory
      b. Data Access Object (DAO) Pattern
      c. Lazy Load Pattern
      d. Procedure Access Object Pattern
      e. Serialized Entity Pattern
      f. Table Inheritance Pattern
      g. Tuple Table Pattern
7. Business Tier Interface Patterns
      a. Business Delegate Pattern
      b. Business Delegate Factory
      c. Service Adapter Pattern
      d. Service Locator Pattern
      e. Session Facade Pattern
8. Concurrency Patterns
      a. ACID Transaction Pattern
      b. Lockable Object Pattern
      c. Lock Manager Pattern
      d. Optimistic Concurrency Pattern
      e. Pessimistic Concurrency Pattern
      f. Transactional Context Pattern
      g. Version Number Pattern

As you can see, there are numerous other patterns in use and to be honest, this list is not exhaustive. This is purely a FYI kind of chapter. Whatever you need to know about design patterns was already covered in the previous chapters, and this chapter is just to tell you that, those 5 are just a drop in the ocean and not the whole thing.

Previous Chapter: Chapter 57 - Front Controller Pattern

Next Chapter: Quick Recap - Chapters 51 to 58

Chapter 56: Model View Controller Pattern

In this chapter, we are going to take a look at one of the most commonly used design patterns in J2EE Application development – the Model View Controller – MVC Pattern.

What is the Model View Controller Design Pattern?

The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller). This pattern is the hardest on the exam. The idea is closely related to the recent move from two-tier to three-tier architectures. The 3 tiers in a MVC Architecture of a J2EE Application are:

1. Model – Usually JavaBeans
2. View – Usually JSPs
3. Controller – Usually Servlets

Is

This pattern is a clear functional separation of roles. It is a formalization of the data-business-presentation movement that dominated three-tier architectures over the last decade.

Is Not

This pattern is very abstract. It is not simply a front end to a datasource connection.

Analogy

This would be like an automobile. The speed of a car is affected by the accelerator pedal (Controller), the speed is shown by the speedometer (View), and the speed is determined by the engine power (Model).

Problem

Different views of the same data are a common need. Conversely, the same client needs access to different models.

Responsibility

This pattern carefully manages communication between the client and model data and functionality. It must allow changing the client or changing the model with minimal impact on the system.

Aim

The main goal is separation of concerns. This pattern attempts to minimize the impact of changing any of the three pieces.

Primary Activity

This pattern decouples views from data and business logic; MVC interjects a controller between them, which interprets user actions into operations on the business logic and the selection of the next view to send to the user.

Context

An application is expected to support varying client and business logic tiers.

Benefits

• Various clients and data models are being developed. These two tiers need to talk to each other.
• Non-interface-specific code is duplicated in many applications.
• The same enterprise data will be accessed by different views: for example, HTML, WML, JFC/Swing, and XML.
• The same enterprise data will be accessed (requested, modified, and deleted) from various actions (HTML links, JFC/Swing events, SOAP XML calls).

Usage

Although the primary purpose of MVC is for building UIs, it can be used to establish an analogous notification protocol between non-visual objects. The Observer/Observable objects in java.util were designed with this pattern in mind.

Consequences

• Clients access a controller that accesses the model instead of the data directly.
• Another layer has to be built which adds work.
• It is easier to break a project into pieces because both the view and model developers are targeting the controller API.

Uses

Almost all J2EE applications use the MVC Pattern. Even JFC Swings technology of Java uses the MVC Pattern. Also, Struts and Velocity use this pattern as their underlying framework.

Previous Chapter: Chapter 55 - Business Delegate Pattern

Next chapter: Chapter 57 - Front Controller Pattern