Enterprise solution patterns using microsoft .net pdf

In other words, the highest-level deployment pattern is about mapping layered applications to a tiered distribution infrastructure and does not impose any additional constraints of its own. Taken as a group, these four high-level constraints, or root constraints, help to narrow the patterns that are in scope for the remainder of this guide. NET Pattlets The use of root constraints reduces the number of patterns to a manageable order of magnitude. Nevertheless, elaborating on all patterns in the grid takes a significant amount of effort.

Patterns need to evolve as the collective understanding of them evolves. Patterns are not created by a single author, but are harvested from actual use in the software development community. Recognizing the evolutionary nature of patterns, the authors of this guide have published the subset of patterns included here to obtain feedback and start building a community. Deferring patterns until later, however, leaves holes in the pattern graph, which could result in related patterns suddenly becoming disconnected.

To preserve the integrity of the relationships inside the pattern graph, this guide includes the patterns that were not included in the first release as pattlets. Pattlets are actual patterns that have not yet been documented in detail.

A pattlet describes a solution to a problem, but does not contain a detailed description of the context, problem, or forces that may impact the solution. The concept of pattlets is also useful for referencing prior pattern works. The patterns community has been discovering and documenting software patterns for over a decade. It would be foolish to try to replicate these efforts. It would also be foolish, however, to require readers to purchase several other books as context for these patterns.

Therefore, this guide includes a pattlet whenever it references a pattern that is described in an existing book about patterns. The pattlet includes the reference to the original work for those readers who would like to look at the complete pattern in more detail. For a detailed list of all pattlets, see Appendix A. Pattern Language for Solutions The constrained Pattern Frame and the patterns it contains provide enough data points to begin using patterns to describe entire solutions.

In fact, the quoting example from Chapter 1 can be described in terms of patterns. Recall that the requirements specified a Web-based quote application. From the application viewpoint, the quote application is an Object-Oriented Application that is logically structured as a Three-Layered Services Application.

From the database viewpoint, the application is based on the OLTP processing model. From the infrastructure viewpoint, the hardware and network architecture are based on Four-Tiered Distribution, which calls for separate physical tiers for Web Chapter 2: Organizing Patterns 27 server and application server functionality. And finally, from the deployment viewpoint, the team has created a Deployment Plan to map components to servers, based on a Complex Web Application.

This concisely describes the architecture of the solution across all four of the viewpoints to anyone familiar with the referenced patterns. Although MVC provides a level of separation between business and presentation logic, each page contains a great deal of common logic.

To eliminate this redundancy, we use a Page Controller to render common headers and footers and set a friendly display name for the user. The domain objects are realized using Table Module [Fowler03] because speed of development is a key requirement. Therefore, the two tiers communicate through a Broker. Business entities, acting in the role of Data Transfer Objects [Fowler03], are used to encapsulate the information traveling between the two tiers.

The data layer uses a Data Table Gateway [Fowler03] to access the OLTP database subsystem and a number of data access components to support the persistence requirements of the domain objects. From the infrastructure viewpoint: to meet the operational requirements of the business, we build on the basic Four-Tiered Distribution model by adding Load Balancing and Server Cluster. Responding to a requirement calling for a high level of concurrent users, we added load balancing to our Web tier.

To meet availability requirements, we added clustering to our database tier. The description could continue on to describe the data and deployment viewpoints at the same level of abstraction. The solution is built using Microsoft. NET technology. The presentation layer is based on the Web presentation framework that is built into ASP. NET simplifies the implementation of Model-View-Controller with the built-in code-behind page feature.

NET to implement our presentation logic. The domain objects in the business layer are managed. NET objects. Because the presentation layer and business layer are deployed on separate tiers, we use Implementing Broker with.

Finally, the data layer is based on the ADO. NET the. NET Framework to provide database access. NET building block. Microsoft Network Load Balancing clusters provide load balancing between Web servers.

All of these conversations make frequent references to patterns. This can be daunting at first, but when you understand the patterns used, you realize that even this brief description gives you a detailed understanding about how the system works. Notice that you gained this understanding without having to wade through reams of documentation or step through endless lines of code.

The communication benefits of patterns become clear if you imagine how much more work would be involved in describing the solution without using patterns. Summary This chapter demonstrated how patterns provide a vocabulary to efficiently describe complex solutions without sacrificing detail.

Effectively, the patterns form a new language with which architects and designers can communicate their thinking. Because of the large number of patterns involved in building enterprise solutions, it can seem difficult to learn this new language. This guide structures the patterns into smaller, more closely related sets of patterns. This allows you to get started by using a smaller set of patterns, depending on your specific interest or the stage of the project.

Relationships between patterns help you to identify patterns that are closely associated to the pattern you are using for example, Page Controller focuses on the controller aspect of Model-View-Controller. Clusters group patterns that belong to a common subject area for example, Web Presentation.

Levels of abstraction allow you to describe concepts in a manner that is consistent with the level of detail of your discussion for example, an architectural conversation. These mechanisms are not meant to constrain your thinking, but instead are intended to make looking at complex systems easier. With practice, you will naturally switch between these mechanisms as you switch between roles, subject areas, and levels of detail.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. Brooks, Jr. As user adoption increased, dynamic Web pages that responded to user input became common. These CGI scripts not only contained the business logic for deciding what to display in response to user input, they also generated the presentation HTML.

As demand for more complex logic increased, so did the demand for richer and more engaging presentations. This increased complexity strained the CGI programming model. This allowed developers to embed script directly into HTML pages, thus simplifying the programming model. As these embedded script applications became more complex, developers wanted to separate out business logic from presentation logic at the page level. In response, tag libraries with helper objects and code-behind page strategies emerged.

Elaborate frameworks appeared, which offered dynamically configurable site navigation and command dispatchers, all at the cost of additional complexity. Given the wide range of Web presentation options now available, how do you choose the appropriate Web presentation design strategy for your application?

This quotation is intended to emphasize the dangers of adding unnecessary complexity to a system. NET Complexity and Redundancy Unfortunately, there is no single design strategy that is right for all situations. This is due to the competing needs in software design to eliminate excessive redundancy and excessive complexity. You can start with a simple page that contains embedded script, and soon the business logic is repeated across files, making the system difficult to maintain and extend.

You can move this logic into a set of collaborating components to eliminate redundancy, but doing so adds complexity to the solution. Instead, you can start off with a framework that offers tag libraries, dynamic configuration, and command dispatchers, but although this eliminates redundant code, it adds a great deal of complexity to the system, often unnecessarily. Adding complexity obscures your intentions, making the system more difficult for other developers to understand.

The added complexity also makes the system harder to maintain and extend, thereby increasing the total cost of ownership. If this added complexity is carefully considered and reserved for meeting current requirements, it can be worthwhile. Extra complexity is sometimes added based on speculation that it might be needed someday, rather than based on current requirements. This can clutter code with unnecessary abstractions that impede understanding and your ability to deliver a working system today.

So, again, how do you wade through the choices to arrive at an appropriate Web presentation design strategy for your application? First, it is important to understand the key Web application design issues, possible solutions, and the associated tradeoffs. This chapter gives developers a strong head start down that path. Sometimes the extra cost is justified, but quite often it is not. Patterns Overview This patterns cluster starts off simply with Model-View-Controller MVC , a longstanding pattern that has stood the test of time when it comes to separating business logic from presentation logic.

Although this pattern is not new [Buschmann96], this collection presents it in a simplified form that is tailored for building business solutions, not for building user interface frameworks for rich clients.

The pattern is written first at the design level, and is then mapped to a platform implementation named Implementing Model-View-Controller in ASP. Figure 3. NET Figure 3. NET starts with an example of a simple system, written on a single page, with application logic embedded in the presentation elements. As complexity grows, the code-behind feature of ASP. NET is used to separate the presentation code view from the model-controller code.

This works well, until requirements drive you to consider reusing the model code, without the controller, to avoid redundancy within your application. At this point, independent models are created to abstract the business logic, and the code-behind feature is used to adapt the model to the view code.

The implementation then finishes off with a discussion about the testing implications of this MVC approach. So far, the use of the Model-View-Controller pattern has focused on the model and the view; the controller plays a relatively minor role.

In fact, the controller at work in this pattern is really the implicit controller in ASP. It is responsible for sensing user events requests and postbacks and wiring those events to the appropriate system response, which in this case is the events in the code-behind page. In dynamic Web-based applications, many common tasks are repeated during each page request, such as user authentication, validation, request parameter extraction, and presentation-related database lookups.

Left unmanaged, these tasks can quickly lead to unnecessary code duplication. Because these tasks have everything to do with sensing user events and determining the proper system response, the logical place to put this behavior is in the controller. This pattern uses a controller at the page scope, accepts input from the page request, invokes the requested actions on the model, and then determines the correct view to use for the resulting page. Duplicate logic, such as validation, is moved into a base controller class.

NET built-in page controller functionality with a common look-and-feel example. The implementation also uses the Template Method [Gamma95] pattern, in conjunction with Page Controller, to define the skeleton of an algorithm in an operation, deferring some of those steps to subclasses.

As more complexity is added to the application, eventually the page controller accumulates a great deal of logic in the base class, a problem which is often solved by deepening the page controller inheritance hierarchy. Given enough complexity, both of these factors lead to code that is hard to maintain and extend. Also, certain applications need dynamic configuration of navigation maps, which would potentially span multiple page controllers.

When this level of complexity occurs, it is time to consider Front Controller. Front Controller, the next pattern in this catalog, is also a refinement of Model-ViewController.

In a front controller, all of the requests are channeled through a single, usually, two-part controller. The first part of the controller is the handler, and the second part is a hierarchy of Commands [Gamma95]. The commands themselves are part of the controller and represent specific actions that the controller triggers.

After the action has executed, the command chooses which view to use to render the page. Usually, this controller framework is built to use a configuration file that maps requests to actions, and is therefore easy to change after it is built. The tradeoff, of course, is in the level of complexity inherent in this design.

Filters and Caching The last two patterns in this cluster involve filters and caching. Intercepting Filter offers a solution to the problem of how to implement common preprocessing and post-processing of the HTTP request. An Intercepting Filter is an ideal place to perform common tasks that are not application-specific, such as security checks, logging, compression, encoding, and decoding.

Intercepting filters are typically concerned with performing one particular task. If multiple tasks execute against the HTTP request, multiple filters are chained together.

Chapter 3: Web Presentation Patterns 33 Page Cache deals with increasing the scalability and performance of Web applications by keeping a copy of often-used dynamic Web pages that are expensive to create.

After the page is initially created, the copy is sent in response to future requests. Page Cache also discusses several key cache design factors such as cache refresh, data freshness, and cache granularity. Web Presentation Patterns The following table lists the patterns included in the Web Presentation patterns cluster.

The patterns are arranged so that later patterns build on earlier patterns. This implies a progression from more general patterns such as Model-ViewController to more specific patterns such as Intercepting Filter.

Table 3. NET Page Controller How do you best structure the controller for moderately complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication? NET Front Controller How do you best structure the controller for very complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication?

NET Using Absolute Expiration Observer How can an object notify other objects of state changes without being dependent on their classes? NET Model-View-Controller Context The purpose of many computer systems is to retrieve data from a data store and display it for the user. After the user changes the data, the system stores the updates in the data store.

Because the key flow of information is between the data store and the user interface, you might be inclined to tie these two pieces together to reduce the amount of coding and to improve application performance. However, this seemingly natural approach has some significant problems. One problem is that the user interface tends to change much more frequently than the data storage system. Another problem with coupling the data and user interface pieces is that business applications tend to incorporate business logic that goes far beyond data transmission.

Problem How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts? For example, new user interface pages may be added, or existing page layouts may be shuffled around.

After all, one of the advantages of a Web-based thin-client application is the fact that you can change the user interface at any time without having to redistribute the application. If presentation code and business logic are combined in a single object, you have to modify an object containing business logic every time you change the user interface.

This is likely to introduce errors and require the retesting of all business logic after every minimal user interface change. For example, when an analyst prefers a spreadsheet view of data whereas management prefers a pie chart of the same data.

In some rich-client user interfaces, multiple views of the same data are shown at the same time. If the user changes data in one view, the system must update all other views of the data automatically. Rarely does a person have both skill sets. Therefore, it is desirable to separate the development effort of these two parts.

User interface activity generally consists of two parts: presentation and update. The presentation part retrieves data from a data source and formats the data for display. When the user performs an action based on the data, the update part passes control back to the business logic to update the data. In Web applications, a single page request combines the processing of the action associated with the link that the user selected with the rendering of the target page.

In many cases, the target page may not be directly related to the action. For example, imagine a simple Web application that shows a list of items. The user returns to the main list page after either adding an item to the list or deleting an item from the list. Therefore, the application must render the same page the list after executing two quite different commands adding or deleting —all within the same HTTP request. User interface code tends to be more device-dependent than business logic.

If you want to migrate the application from a browser-based application to support personal digital assistants PDAs or Web-enabled cell phones, you must replace much of the user interface code, whereas the business logic may be unaffected. A clean separation of these two parts accelerates the migration and minimizes the risk of introducing errors into the business logic. Creating automated tests for user interfaces is generally more difficult and timeconsuming than for business logic.

Therefore, reducing the amount of code that is directly tied to the user interface enhances the testability of the application. The model manages the behavior and data of the application domain, responds to requests for information about its state usually from the view , and responds to instructions to change state usually from the controller. The view manages the display of information. Controller Model View Figure 3. However, the model depends on neither the view nor the controller.

This is one the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation. The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In Web applications, on the other hand, the separation between view the browser and controller the server-side components handling the HTTP request is very well defined.

Model-View-Controller is a fundamental design pattern for the separation of user interface logic from business logic. Unfortunately, the popularity of the pattern has resulted in a number of faulty descriptions. Fortunately, the advent of Web applications has helped resolve some of the ambiguity because the separation between the view and the controller is so apparent. The passive model is employed when one controller manipulates the model exclusively.

The controller modifies the model and then informs the view that the model has changed and should be refreshed see Figure 3. The model in this scenario is completely independent of the view and the controller, which means that there is no means for the model to report changes in its state. The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server.

The browser displays the view and responds to user input, but it does not detect changes in the data on the server. Only when the user explicitly requests a refresh is the server interrogated for changes. This can happen when other sources are changing the data and the changes must be reflected in the views. Consider a stock-ticker display. You receive stock data from an external source and want to update the views for example, a ticker band and an alert window when the stock data changes.

Because only the model detects changes to its internal state when they occur, the model must notify the views to refresh the display.

However, one of the motivations of using the MVC pattern is to make the model independent from of the views. If the model had to notify the views of changes, you would reintroduce the dependency you were looking to avoid.

Fortunately, the Observer pattern [Gamma95] provides a mechanism to alert other objects of state changes without introducing dependencies on them.

The individual views implement the Observer interface and register with the model. The model tracks the list of all observers that subscribe to changes. When a model changes, the model iterates through all registered observers and notifies them of the change. In fact, in scenarios where the controller needs to be informed of model changes for example, to enable or disable menu options , all the controller has to do is implement the Observer interface and subscribe to the model changes.

In situations where there are many views, it makes sense to define multiple subjects, each of which describes a specific type of model change. Each view can then subscribe only to types of changes that are relevant to the view. Unfortunately, there is no good way to demonstrate the separation of model and view in a Unified Modeling Language UML sequence diagram, because the diagram represents instances of objects rather than classes and interfaces.

Testing Considerations Testability is greatly enhanced when you employ employing Model-View-Controller. Testing components becomes difficult when they are highly interdependent, especially with user interface components. These types of components often require a complex setup just to test a simple function.

Worse, when an error occurs, it is hard to isolate the problem to a specific component. This is the reason why separation of concerns is such an important architectural driver. MVC separates the concern of storing, displaying, and updating data into three components that can be tested individually.

Apart from the problems posed by interdependencies, user interface frameworks are inherently difficult to test. Testing user interfaces either requires tedious and error-prone manual testing or testing scripts that simulate user actions.

These scripts tend to be time-consuming to develop and brittle. MVC does not eliminate the need for user interface testing, but separating the model from the presentation logic allows the model to be tested independent of the presentation and reduces the number of user interface test cases. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects.

Another example is a Web application that allows the user to change the appearance of the pages. These pages display the same data from the shared model, but show it in a different way.

Accommodates change. User interface requirements tend to change more rapidly than business rules. Users may prefer different colors, fonts, screen layouts, and levels of support for new devices such as cell phones or PDAs. Because the model does not depend on the views, adding new types of views to the system generally does not affect the model.

As a result, the scope of change is confined to the view. This pattern lays the foundation for further specializations of this pattern such as Page Controller and Front Controller.

The MVC pattern introduces new levels of indirection and therefore increases the complexity of the solution slightly. It also increases the event-driven nature of the user-interface code, which can become more difficult to debug.

Cost of frequent updates. Decoupling the model from the view does not mean that developers of the model can ignore the nature of the views. For example, if the model undergoes frequent changes, it could flood the views with update requests. Some views, such as graphical displays, may take some time to render. As a result, the view may fall behind update requests. Therefore, it is important to keep the view in mind when coding the model. For example, the model could batch multiple updates into a single notification to the view.

Variants The Document-View variant recognizes all three roles of Model-View-Controller but merges the controller into the view. The document corresponds to the model role in MVC. This variant is present in many existing GUI platforms.

The tradeoff of using this variant is that the view and the controller are more tightly coupled. This pattern is often mentioned in conjunction with MVC due to the need to keep the views and the associated model synchronized.

Acknowledgments Model-View-Controller began as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late s [Fowler03]. The version you have just read references the following works: [Burbeck92] Burbeck, Steve. Patterns of Enterprise Application Architecture.

AddisonWesley, Addison-Wesley, NET, and, based on the complexity of your application, you need to separate different aspects of the program to reduce code duplication and to limit the propagation of change. NET and the value provided by separating the model, view, and controller roles in software, the following example refactors a single-page solution, which does not separate all three roles, into a solution that separates the roles. The example application is a single Web page shown in Figure 3.

The application then retrieves the list of all tracks from this recording from the database and displays the results in a table. All three solutions described in this pattern implement the exact same functionality. Fill ds, "Recording" ; recordingSelect. Fill ds, "Track" ; MyDataGrid. The view role is represented by the HTML-specific rendering code. This page uses an implementation of Bound Data Control to display the DataSet object that is returned from the database.

The controller role is not represented directly, but it is implicit in ASP. NET; see Page Controller. The page updates when the user makes a request. Model-View-Controller describes this as a passive controller. NET implements the controller role, but the programmer is responsible for connecting the actions to the events to which the controller will respond. This page is very straightforward and self-contained. The implementation is useful, and is an excellent starting point when the application is small and does not change very often.

You may want different people working on the view code and the model code to increase the amount of parallelism and limit the potential for introducing errors. For example, if all of the code is in one page, a developer could change the formatting of the DataGrid and inadvertently change some of the source code that accesses the database.

You would not discover this error until the page was viewed again, because the page is not compiled until it is viewed. In this current implementation, there is no way to reuse any of the code in other pages without duplicating it. Duplicate code is difficult to maintain, because if a change occurs in the database code, you have to modify all the pages that access the database. To address some of these issues, the implementers of ASP. NET introduced the codebehind feature.

NET development system makes it easy to separate the presentation view code from the model-controller code. Each ASP. NET page has a mechanism that allows methods that are called from the page to be implemented in a separate class. This mechanism is facilitated by Visual Studio. When you use the code-behind feature to implement your pages, you can use IntelliSense to show a list of available methods of the objects that you are using in the code behind the page.

IntelliSense does not work in. The following is the same example, this time using the code-behind feature to implement ASP. View The presentation code is now in a separate file called Solution. The main difference is the first line: This line indicates to the ASP. NET environment that a code-behind class implements methods that are referenced in this page.

Because the page is free of any code that accesses the database, there is no longer any need to modify this page if the database access code changes. Someone who is familiar with the design of the user interface can modify this code without introducing any errors to the database access code. Data; using System. Page System. Button submit; System. EventHandler this. NET page into its own file. A few syntactic changes are required to link the two entities together.

The member variables defined in the class share the same name as the ones referenced in the Solution. The other aspect that must be explicitly defined is how the controller links the events that occur to the actions that must be performed.

The InitializeComponent method links the two events in this example. The code-behind feature is an elegant mechanism for separating the view role from the model and controller roles. It may become insufficient when you need to reuse the code that is present in the code-behind class for another page. It is technically possible to reuse the code from the code-behind page, but highly undesirable, due to the increase in coupling of all the pages that share the code-behind class.

Model-View-Controller Refactoring To resolve the last issue, you need to further separate the model code from the controller. The view code is identical to the code used in the previous implementation. Model The following code example describes the model and is dependent on the database only; it does not contain any view-dependent code code with ASP.

Collections; System. Data; System. This class is an excellent example of a Table Data Gateway. A Table Data Gateway holds all the SQL code for accessing a single table or view; selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database. Because the model here returns a DataSet object, its job is straightforward. This code, like the view code, does not depend on how data is retrieved from the database.

NET using using using using System; System. GetRecordings ; recordingSelect. GetTracks string recordingSelect. Value ; MyDataGrid. NET environment makes testing of the model code easier. To test this code inside the ASP. NET environment, you must test the output of the process. This means reading HTML and determining if it is correct, which is tedious and error-prone. The separation of the model so that it can run without ASP. NET allows you to avoid the tedium and test the code in isolation.

Framework; System. GetTracks "" ; Assertion. AssertEquals 10, ds. AssertEquals 3, ds. GetRecordings ; Assertion. AssertEquals 4, ds. Tables["Recording"]; Assertion. AssertEquals 4, recording. AssertEquals "Up", title. An ASP. NET page allows the programmer to implement methods within a page.

As the Single ASP. NET Page shows, this can be useful for prototypes and small short-lived Web applications. As the complexity of the page, or the need to share code between pages, increases, it becomes more useful to separate portions of the code. Reduced code duplication. This eliminates the need to copy the methods into multiple views. Separation of duties and concerns. The skill set for modifying the ASP. Enterprise Solution Patterns Using Microsoft. Net by Microsoft Corporation.

NET embraces existing work in the patterns community, contributes new patterns, and shows how to implement these patterns in. Included in the guide are an introduction to patterns and a catalog of 32 architecture, design, and implementation patterns.

This guide introduces patterns and then presents them in a repository, or catalog, organized to help you locate the right combination of patterns that solve your problem. Home page url. Net and C , the examples have a greater appeal.

To make you a better professional, add to your armoury of proven solutions to common software design problems and steal a march over colleagues who still rely on personal experience and intuition rather than tapping into the combined experience of hundreds of successful developers distilled into a powerful, readable, practical book.

Gregor Hohpe Homepage No information is available for this author. David Lavigne No information is available for this author. Dave Mancini No information is available for this author. James Newkirk Homepage No information is available for this author.

Dave Quick No information is available for this author.