Patterns Of Enterprise Application Architecture

Transcription

1 Patterns Of Enterprise Application Architecture

2 Lecture Outlines Overview of patterns Web Presentation Patterns Base Patterns Putting It All Together

3 References Domain Logic Patterns Domain Model Data Source Architectural Patterns Object-Relational Behavioral Patterns Object-Relational Metadata Mapping Patterns Web Presentation Patterns Distribution Patterns Offline Concurrency Patterns Session State Patterns Base Patterns

4 Web Presentation Patterns Model-View-Controller is a widely referenced pattern but one that's often misunderstood

5 Web Presentation Patterns Model-View-Controller (continue) View display of the model Controller takes input manipulates model causes the view updates appropriately Model all data and behaviour other then used in UI

6 Web Presentation Patterns Model-View-Controller (continue) Presentation layer controller, View Model the presentation layer depends on model multiple view updates its state Presentation-Model separation Different thinks Multiple presentations available Better testing of non-visual thinks View-Controller separation Support for different behavior of the same view

7 Web Presentation Patterns List of patterns View Patterns Transform View Template View Two Step View Input Controller Patterns Page Controller Front Controller Application Controller

8 Page Controller An object that handles a request for a specific page or action on a Web site. How It Works to have one module on the Web server act as the controller for each page on the Web site. Page Controller: Decode the URL and extract any form data to figure out all the data for the action. Create and invoke any model objects to process the data. All relevant data from the HTML request should be passed to the model so that the model objects don't need any connection to the HTML request. Determine which view should display the result page and forward the model information to it.

9 Page Controller (continued) Two kinds Script Server Page (JSP, PHP, ASP) it often combines the Page Controller and a Template View in one page works less for the Page Controller When to Use It Decision between Page Controller and Front Controller Works particularly well in a site with simple controller logic

10 Page Controller Example

11 Front Controller A controller that handles all requests for a Web site. How it Works handles all calls for a Web site, and is usually structured in two parts: a Web handler and a command hierarchy. A particularly useful pattern to use in conjunction with Front Controller is Intercepting Filter

12 Front Controller (continued) When to Use It The Front Controller is a more complicated design than its obvious counterpart, Page Controller Only one Front Controller has to be configured into the Web server Because you create new command objects with each request, you don't have to worry about making the command classes thread-safe. There's just one controller, so you can easily enhance its behavior at runtime with decorators

13 Front Controller Example

14 Template View Renders information into HTML by embedding markers in an HTML page. How It Works The basic idea of Template View is to embed markers into a static HTML page when it's written. Embedding the Markers HTML-like tags Helper Object Conditional display Iteration

15 Template View (Continue) When to Use It Choice between it and Transform View Positive: it allows you to compose the content of the page by looking at the page structure. it nicely supports the idea of a graphic designer laying out a page with a programmer working on the helper. Negative the common implementations make it too easy to put complicated logic in the page, thus making it hard to maintain, particularly by nonprogrammers The second weakness is that Template View is harder to test than Transform View

16 Template View Example

17 Transform View A view that processes domain data element by element and transforms it into HTML. How It Works The basic notion of Transform View is writing a program that looks at domain-oriented data and converts it to HTML. You can write a Transform View in any language; at the moment, however, the dominant choice is XSLT.

18 Transform View (continued) When to Use It One of the strengths of XSLT is its portability to almost any Web platform XSLT is also often easier if you're building a view on an XML document Transform View avoids two of the biggest problems with Template View: It's easier to keep the transform focused only on rendering HTML, thus avoiding having too much other logic in the view It's also easy to run the Transform View and capture the output for testing.

19 Transform View Example

20 Two Step View Turns domain data into HTML in two steps: first by forming some kind of logical page, then rendering the logical page into HTML. How It works The key to this pattern is in making the transformation to HTML a two-stage process. assembles the information in a logical screen structure that is suggestive of the display elements yet contains no HTML takes that presentation-oriented structure and renders it into HTML

21 Two Step View (continued) When to Use It allowing you to make global changes more easily. singleappearance Web applications

22 Two Step View (continued) When to Use It Multiappearance Web applications

23 Application Controller A centralized point for handling screen navigation and the flow of an application. How It Works An Application Controller has two main responsibilities: deciding which domain logic to run and deciding the view with which display the response.

24 Application Controller (continued) When to Use It If the flow and navigation of your application are simple enough so that anyone can visit any screen in pretty much any order, there's little value in a Application Controller To definite rules about the order in which pages should be visited and different views depending on the state of objects.

25 Application Controller Example

26 Application Controller Example (continued)

27 Application Controller Example (continued)

28 Distribution Strategies

29 Distribution Strategies (continued) Remote and Local Interfaces Where Yout Have to Distribute Client-server Server-based application software and the database Web server and application server because of vendor differences Working with the Distribution Boundary Interfaces for Distribution

30 Distribution Patterns Remote Facade Data Transfer Object

31 Remote Facade How It Works Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network. To allow efficient remote access to fine grained objects, I make a separate facade object that acts as a remote interface. the facade is merely a thin skin that switches from a coarsegrained to a fine-grained interface

32 Remote Facade When to Use It Whenever you need remote access to a fine-grained object model. You gain the advantages of a coarse-grained interface while still keeping the advantage of finegrained objects, giving you the best of both worlds. in case of high cost of inter-process communication.

33 Data Transfer Object How It Works An object that carries data between processes in order to reduce the number of method calls.. Often little more than a bunch of fields and accessors and mutators. Whenever a remote object needs some data, it asks for a suitable Data Transfer Object. It will usually carries much more data than what the remote object requested. A single Data Transfer Object usually contains more than just a single server object.

34 Data Transfer Object When to Use It Whenever you need to transfer multiple items of data between two processes in a single method call. some alternatives to Data Transfer Object: Use a setting method with many arguments or a getting method with several pass-by reference argument. to use a some form of string representation directly

35 Data Transfer Object Assembling a Data Transfer Object from Domain Objects The assembler is an example of a Mapper (kind of base patterns)

36 Base Patterns Gateway An object that encapsulates access to an external system or resource.

37 Base Patterns Mapper An object that sets sup a communication between two independent objects.

38 Base Patterns Layer Supertype A type that acts as the supertype for all types in its layer.

39 Base Patterns Separated Interface Defines an interface in a separate package from its implementation. When to use: You've built some abstract code for common cases into a framework package that needs to call some particular application code. You have some code in one layer that needs to call code in another layer that it shouldn't see, You need to call functions developed by another development group but don't want a dependency into their APIs.

40 Base Patterns Registry A well-known object that other objects can use to find common objects and services. Despite the encapsulation of a method, a Registry is still global data and you should only use a Registry as a last resort.

41 Base Patterns Value Object A small simple object, like money or a date range, whose equality isn't based on identity. The key difference between reference and value objects lies in how they deal with equality: Reference objects equality based on identity (system or some ID e.g. primary key) Value objects equality based on values of instance variables. Use attribute in classes for value object instead associations (references).

42 Base Patterns Money Represents a monetary value.

43 Base Patterns Special Case A subclass that provides special behavior for particular cases.

44 Base Patterns Plugin Links classes during configuration rather than compilation.

45 Base Patterns Service Stub Removes dependence upon problematic services during testing. Synonym for Mock Object service Service Stub is older.

46 Base Patterns Record Set An in-memory representation of tabular data.

47 Putting It All Together Starting with the Domain Layer: Transaction Script or Table Module or Domain Model Data Source For Transaction Script Row Data Gateway or Table Data Gateway(having a platform that provides a lot of tools for RecordSet), consider Unit of Work and Optimistic Offline Lock for concurrency Table Module (good RecordSet framework) implies TableDataGateway DomainModel ActiveRecord a DM is fair simple DataMapper - a DM is more complicated, O/R mapping patterns come into play, Martin Fowler strongly suggest getting a mapping tool.

48 Putting It All Together (continued) Presentation layer MVC recomended choose controller and view VS Page Controller, Template View Struts Front Controller, TemplateView communication with lower layer in one process Remote Facade and use DTO