Programming Jakarta Struts By Chuck Cavaness - Part3

Couple Of Days i started reading Programming Jakarta Struts By Chuck Cavaness.

Nice book written by Chuck Cavaness.

I wanted to share few quotations found from the next 2 chapters(5-6) from this book.

1) Using a controller provides a centralized point of control where all client requests are initially processed. Centralizing control in this way realizes two requirements of MVC design. First, the controller acts as the mediator/translator between client input and the model, providing common functionality such as security, logging, and other important services on behalf of each client request. Second, because all requests are filtered through the controller, the view is decoupled both from the business logic and from other view components. The view returned to the client is entirely up to the controller. This makes your applications much more flexible.

2) The J2EE Front Controller design pattern uses a single controller to funnel all client requests through a central point. Among the many advantages this pattern brings to application functionality is that services such as security, internationalization, and logging are concentrated in the controller. This permits the consistent application of these functions across all requests. When the behavior of these services needs modification, changes potentially affecting the entire application need to be made only to a relatively small and isolated area of the program.

3) The Struts controller has several responsibilities. Chief among these are:

· Intercepting client requests.

· Mapping each request to a specific business operation.


· Collecting results from the business operation and making them available to the client.

· Determining the view to display to the client based on the current state and result of the business operation.


4) The org.apache.struts.action.ActionServlet class acts as an interceptor for a Struts application. All requests from the client tier must pass through the ActionServlet before proceeding anywhere else in the application.

5) The model components of an application arguably are the most valuable software artifacts to an organization. The model includes the business entities and the rules that govern access to and modification of the data. It's vital that this be kept in a single location in order to maintain valid data integrity, reduce redundancy, and increase reusability.

During analysis of the problem domain, a conceptual model should be developed based on the real-life entities within the problem space. The entities in a conceptual model have less to do with the software components of the system and more to do with the physical entities that are fundamental to the business. The conceptual model usually illustrates the concepts, the relationships between them, and the attributes that belong to each concept. The behavior usually is not represented in this type of model.

6) This question may sound a little too simplistic for a book on Struts. However, the term "business object" has many connotations, and some developers use it when they really mean something else. A business object (BO) is simply a software abstraction of a real-world entity. It represents a person, place, thing, or concept from the business domain. So, concepts such as items, orders, and customers are all business objects from the Storefront business domain.

7) In general, persistence means that the data that is input into an application, either by a human user or by other means, will exist beyond the lifetime of the application. Even though the application may exit or the computer may shut down, the information will survive. This obviously is very important to an organization. Every small, medium, and large organization has the need to persist data.


About the Author

Chuck Cavaness is a graduate from Georgia Tech with degrees in computer engineering and computer science, has built Java-based enterprise systems in the healthcare, banking, and B2B sectors. Working at an Internet company to design and develop software architecture, Chuck has spent many frustrating hours figuring out the dos and the don'ts of web applications. With each enterprise system he's developed, Chuck has learned several valuable lessons about building "real-world" web applications, information that he's made available to developers who haven't had the opportunity to work on large systems.

Chuck is the co-author of Special Edition Using Java 1.3 and Special Edition Using EJB 2.0, both available from QUE.