When we speak about Presentation Logic, we talk about how we display these objects to a user, e.g. do we have a drop-down list or a popup screen? Do we display accounts in a list format and have the user pick which one to edit? This is often referred to as the View in the MVC paradigm (see MVC discussion above). It is often difficult to determine where business logic ends, and presentation logic begins. How you model your application often dictates what is possible in the user interface. Sometimes the business and presentation logic are so intricate and dependent on each other that the two get intertwined with each other. Sometimes it is often difficult or impossible to separate the two. In most other cases, separating the two is just a matter of discipline.
There are several reasons why separating business logic from presentation logic is desired. Below are a couple of reasons why we did it.
-
Separating the two allows one to use the best tools and solutions for that part.
-
The two parts - business logic and presentation logic - do not always occur at the same time. For example, many times screens are designed first (as part of the business requirements) and the business logic implementation comes later. Separating the two minimizes time dependency and allows for concurrent development. You can work on each part independently and then integrate them later or integrate in an iterative fashion.
-
Separation of Workforce - This is important for big organizations with very specialized people but is less important for small shops where often the programming of all parts is done by the same person.
-
Separation of Thought and Readability of code - It is easier to read business logic that is not intermingled with presentation logic. Similarly, it is easier to look at the presentation of a screen or read html code without having to sift through the database and security logic.
HTML-based applications became popular because the cost of deployment was low, the architecture was simple, and HTML was trivially easy to learn and use. Many users and developers were willing to give up the user interface improvements brought by desktop computers in return for immediate access to new data and applications. The benefits of being Web-based outweighed the loss of significant UI functionality.
Certain applications, however, are not a good fit with HTML. Complex applications may require several page redraws to complete a transaction, and in certain fields such as medicine and finance, this can mean unacceptably slow interaction. Consider a project management system: It can be handled as an HTML application, but it certainly works better when users can see and manipulate charts, schedules, and hierarchies.
Furthermore, although HTML starts off simple, even simple interactivity can require a lot of scripting to get the job done. And even if an input form is carefully laid out and fully scripted, all it can send from the browser is simple name/value pairs. It would be nice if an HTML form could send and receive more-complex data structures in the form of XML documents.
Based on all factors mentioned above, implemented architecture represents combination of the best features available from both light-weight HTML and rich client. Gateway architecture (described above) also contributed to the clean and efficient implementation of the presentation tier.
As shown on the diagram above, all front-end and integration clients use XML as communication "language". Web client also was not an exception. The following is the way it works: Initial page is created using standard Java server page. This initial page contains no data but acts just as a template for the page that will be presented to the user. As soon as page is loaded into the browser java code executes and sends request for the data to the XML application gateway. Data is sent back to the browser in the form of XML response. Data is processed by a combination of the Microsoft XSLT engine and JavaScript and designated areas on the page (called "data islands") are populated. Only after this the page is "presented" to the user.
Significant advantages of such an approach are:
-
Java server page is used as the template; thus, it does not have to be re-drawn every time data on the page changes. This is the behavior of a rich client rather than thin HTML client.
-
Page processing is shifted from server to the client increasing overall scalability of the application.
-
Presentation logic and functionality remain mostly separated from the business logic back- end tier. This also makes development and maintenance of the code much easier.
Navigation (and session management) functionality is implemented using modified Struts framework. Introduced modifications allow seamless and uniform support for XSLT processing and navigation state management.
Another valuable advantage of client-side rendering approach is an ability to customize the look and feel of the front end using only browser without the third-party tools. Application can be customized not only on the customer level, but also tuned for the preferences of the specific user.