The Other 2.

0
Architectural
Patterns and Styles
 Relevant Technologies

Mobile Applications. You can use presentation-layer technologies such as the

.NET Compact Framework, ASP.NET for Mobile, and Silverlight for Mobile to
develop applications for mobile devices.
l Rich Client Applications. You can use combinations of Windows Presentation
Foundation (WPF), Windows Forms, and XAML Browser Application (XBAP)
presentation-layer technologies to develop applications with rich UIs that are
deployed and run on the client.
l Rich Internet Client Applications (RIA). You can use the Microsoft Silverlight™
browser plug-in, or Silverlight combined with AJAX, to deploy rich UI experiences
within a Web browser.
Web Applications. You can use ASP.NET Web Forms, AJAX, Silverlight controls,
ASP.NET MVC, and ASP.NET Dynamic data to create Web applications.
l Service Applications. You can use Windows Communication Foundation (WCF)
and ASP.NET Web services (ASMX) to create services that expose functionality to
external systems and service consumers.
Layered Application
Guidelines
Services Layer
Design Steps for a Layered Structure

|Step 1 – Choose Your Layering Strategy

l Step 2 – Determine the Layers You Require

l Step 3 – Decide How to Distribute Layers and Components

l Step 4 – Determine If You Need to Collapse Layers

l Step 5 – Determine Rules for Interaction between Layers

l Step 6 – Identify Cross Cutting Concerns

l Step 7 – Define the Interfaces between Layers

l Step 8 – Choose Your Deployment Strategy

l Step 9 – Choose Communication Protocols

Presentation Layer Guidelines
 Choose the appropriate application type

Choose the appropriate UI technology.

Use the relevant patterns

Design for separation of concerns

Consider human interface guidelines.

Adhere to user driven design principles

Design Steps for the Presentation Layer

1. Identify your client type

2. Choose your presentation layer technology

3. Design your user interface

4. Determine your data validation strategy

5. Determine your business logic strategy.

UI Validation
Business Process Components.
Domain Model
Rules Engine
6 Determine your strategy for communication with other layers.
Direct method calls
Web services
Business Layer Guidelines
 Business Workflow components
Business Entity components

Specific Design Issues

l Authentication
l Authorization
l Caching
l Coupling and Cohesion
l Exception Management
l Logging, Auditing, and Instrumentation
l Validation
Relevant Design Patterns
Data Layer Guidelines
Specific Design Issues

l Batching
l Binary Large Objects (BLOBs)
l Connections
l Data Format
l Exception Management
l Object Relational Mapping
l Queries
l Stored Procedures
l Stored Procedures vs. Dynamic SQL
l Transactions
l Validation
l XML
Stored Procedures
In the past, stored procedures represented a performance improvement over dynamic
SQL statements. However, with modern database engines, the performance of stored
procedures and dynamic SQL statements (using parameterized queries) are generally
similar. When considering the use of stored procedures, the primary factors are
abstraction, maintainability, and your environment.

l Use typed parameters as input values to the procedure and output parameters to
return single values. Consider using XML parameters or table-value parameters for
passing lists or tabular data. Do not format data for display in stored procedures;
instead, return the appropriate types and perform formatting in the presentation
layer.
l Use parameter or database variables if it is necessary to generate dynamic SQL
within a stored procedure. However, bear in mind that using dynamic SQL in
stored procedures can affect performance, security, and maintainability.
l Avoid the creation of temporary tables while processing data. However, if
temporary tables must be used, consider creating them in memory instead
of on disk.
l Implement appropriate error handling designs, and return errors that the
application code can handle.
Relevant Design Patterns
Service Layer Guidelines
l Service interfaces. Services expose a service
interface to which all inbound
messages are sent. You can think of a service
interface as a façade that exposes
the business logic implemented in the
application (typically, logic in the business
layer) to potential consumers.

l Message types. When exchanging data across

the service layer, data structures
are wrapped by message structures that
support different types of operations. The
services layer will also usually include data
types and contracts that define the data
types used in messages.
l Design services to be application-scoped and
not component-scoped. Service
operations should be coarse grained and
focused on application operations.
Defining service operations that are too fine
grained can result in performance
or scalability problems.

l Design services and data contracts for

extensibility and without the assumption
that you know who the client is. In other
words, data contracts should be designed
so that, if possible, you can extend them
without affecting consumers of the service.
l Design only for the service contract. The
service layer should implement and
provide only the functionality detailed in the
service contract, and the internal
implementation and details of a service should
never be exposed to external l Design to assume the possibility
consumers. Also, if you need to change the of invalid requests. You should
service contract to include new never assume
functionality implemented by a service, and that all messages received by the
the new operations and types are service are valid.
not backward compatible with the existing
contracts, consider versioning your
contracts.

l Compose entities from standard elements.

When possible, use standard elements
to compose the complex types and data
transfer objects used by your service
l Ensure that the service can detect and
manage repeated messages (idempotency).
When designing the service, implement well-
known patterns such as Idempotent
Receiver and Replay Protection to ensure that
duplicate messages are not processed,
or that repeated processing has no effect on
the result.

l Ensure that the service can manage

messages arriving out of order
(commutativity).
If it is possible that messages will arrive out of
order, implement a design that will
store messages and then process them in the
correct order.
l Ensure that secure protocols such as Secure
Sockets Layer (SSL) are used when
you use Basic authentication, or when
credentials are passed as plain text. Consider
using message-level security mechanisms
supported by the WS* standards
(Web Services Security, Web Services Trust,
and Web Services SecureConversation)
with SOAP messages.
l Set appropriate access permissions
on resources for users, groups, and
roles.
Execute services under the most
restrictive account that is
appropriate

l Use URL authorization and/or file

authorization when using Windows
authentication.
l Analyze your communication requirements
and determine if you need requestresponse
or duplex communication, and if message
communication must be one
way or two way.

l Determine how to handle unreliable or

intermittent communication, perhaps by
implementing a service agent or using a
reliable message queuing system such as
Message Queuing.

l If the service will be deployed within a closed

network, consider using Transmission
Control Protocol (TCP) to maximize
communication efficiency. If the service
will be deployed into a public facing network,
consider using the Hypertext
Transfer Protocol (HTTP).
Design Steps for the Service Layer

1. Define the data and message contracts that represent the schema used for
messages.
2. Define the service contracts that represent operations supported by your
service.
3. Define the fault contracts that return error information to consumers of the
service.
4. Design transformation objects that translate between business entities and
data
contracts.
5. Design the abstraction approach used to interact with the business layer.
Component Guidelines
 General Guidelines for Component Design

l Apply the SOLID design principles to the classes within your component
l Single responsibility principle. A class should have only responsibility.
l Open/closed principle. Classes should be extensible without requiring
modification.
l Liskov substitution principle. Subtypes must be substitutable for their
base types.
l Interface segregation principle. Class interfaces should be client specific
and fine grained. Classes should expose separate interfaces for different
clients where the interface requirements differ.
l Dependency inversion principle. Dependencies between classes should
be replaced by abstractions to allow top down design without requiring
design of low level modules first. Abstractions should not depend upon
details—details should depend upon abstractions.

l Apply the key principles of the component-based architectural style. These

principles are that components should be reusable, replaceable, extensible,
encapsulated, independent, and not context specific.
 General Guidelines for Component Design

l Design components to be highly cohesive. Do

not overload components by
adding unrelated or mixed functionality.
l A component should not rely on internal
details of other components. Each
component or object should call a method of
l Understand how components will another object or component, and
communicate with each other. This that method should have information about
requires how to process the request and, if
an understanding of the deployment appropriate, how to route it to appropriate
scenarios your application must subcomponents or other components.
support.

l Keep crosscutting code abstracted from the application-specific logic.

Crosscutting code refers to code related to security, communications, or operational
management such as logging and instrumentation. Mixing the code that
implements these functions with the component logic can lead to a design
that is difficult to extend and maintain.
 Components Types

l Presentation Logic Components

Presentation logic components are primarily concerned with implementing the
application's use cases (or user stories), and orchestrating the user’s interactions
with the underlying logic and state of the application in a UI independent way.
They are also responsible for organizing data from the business layer in a
consumable format for the UI components
l Presenter, Controller, Presentation Model, and ViewModel Components.
Used when implementing the Separated Presentation pattern, these kinds
of components often encapsulate presentation logic within the presentation
layer. To maximize reuse opportunities and testability, these components are
not specific to any specific UI classes, elements, or controls.
l Presentation Entity Components. These components encapsulate business
logic and data and make it easy for the UI and presentation logic components
in the presentation layer to consume; for example, by performing data type
conversion or by aggregating data from several sources. In some cases, these
are the business entities from the business layer consumed directly by the
presentation tier
 Components Types

l User Interface Components

l Service Interfaces. Services expose a service interface to which all inbound

messages are sent.
l Message Types. When exchanging data across the service layer, data
structures are wrapped by message structures that support different types
of operations.

l Application Façade. This optional component

typically provides a simplified
interface to the business logic components,
often by combining multiple business
operations into a single operation that makes it
easier to use the business logic,
and reduces dependencies because external
callers do not need to know details
of the business components and relationships
between them.
 Components Types

l Business Workflow Components. After the UI

components collect input
from the user and pass it to the business layer,
the application can use this
input to perform a business process. l Business Entity Components. Business
entities, or—more generally—
business objects, encapsulate the business
logic and data necessary to
represent real world elements, such as
Customers or Orders, within your
application. They store data values and expose
them through properties;
contain and manage business data used by the
application; and provide
stateful programmatic access to the business
data and related functionality.
Business entities also validate the data
contained within the entity
and encapsulate business logic to ensure
consistency and to implement
business rules and behavior.
 Components Types

l Data Access Components. These components

abstract the logic required to access
the underlying data stores. Most data access
tasks require common logic that can
be extracted and implemented in separate
reusable helper components or a suitable
support framework. This can reduce the
complexity of the data access components
and centralize the logic, which simplifies l Service Agents. When a business component
maintenance. must use functionality provided by
an external service, you might need to
implement code to manage the semantics of
communicating with that particular service.
Service agents isolate the idiosyncrasies
of calling diverse services from your
application, and can provide additional
services such as caching, offline support, and
basic mapping between the format
of the data exposed by the service and the
format your application requires.
 Components Types

l Components for implementing security. These

may include components that
perform authentication, authorization, and
validation.

l Components for implementing operational

management tasks. These may
include components that implement exception
handling policies, logging, performance
counters, configuration, and tracing.

l Components for implementing

communication. These may include components
that communicate with other services and
applications.
Designing
Presentation
Components
Step 1 – Understand the UI Requirements
Step 2 – Determine the UI Type Required
Step 3 – Choose the UI Technology
l Microsoft .NET Compact Framework l Silverlight with AJAX
l Windows Presentation Foundation (WPF). l ASP.NET Web Forms.
l Windows Forms with WPF User Controls l ASP.NET MVC
l Silverlight for Mobile. l Windows Forms
| WPF with Windows Forms User Controls l ASP.NET for Mobile.
l XAML Browser Application (XBAP) using WPF

Step 4 – Design the Presentation Components

Step 4 – Design the Presentation Components