Application Architecture Guide 2.0 BETA 1 - Willy .Net

More documents

Recommendations

Info

Presentation Layer Components • User interface (UI) components. User interface components provide a way for users to interact with the application. They render and format data for users and acquire and validate data coming in from them. • User process components. To help synchronize and orchestrate these user interactions, it can be useful to drive the process using separate user process components. This means that the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction patterns can be reused by multiple user interfaces. 26
Services Layer Components • Service Interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service, in order for the service to perform a specific business task, constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers. • Message Types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers. Business Layer Components • <strong>Application</strong> Facade. (Optional). Use a façade to combine multiple business operations into a single messaged-based operation. You might access the application façade from the presentation layer using different communication technologies. • Business components. Business components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks. • Business workflows. After the required data is collected by a user process, the data can be used to perform a business process. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools. • Business entity components: Business entities are used to pass data between components. The data represents real-world business entities, such as products and orders. The business entities used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order. Data Layer Components • Data access logic components. Data access components abstract the logic necessary to access your underlying data stores. They centralize data access functionality, and make the process easier to configure and maintain. • Data helpers / utility components. Helper and utility components contain logic and functions that are used in several data layer components. This provides faster development, eases maintenance and promotes code reuse. • Service agents. When a business component must use functionality exposed by an external service, you may need to provide some code to manage the semantics of communicating with that service. Service agents isolate the idiosyncrasies of calling diverse services from 27
Page 1 and 2: Application Architecture Guide 2.0
Page 3 and 4: Application Architecture Guide 2.0
Page 5 and 6: App Types Architecture Styles Scena
Page 7 and 8: • Use it when you design applicat
Page 9 and 10: Feedback on the Guide If you have c
Page 11 and 12: Architecture and Design Best Practi
Page 13 and 14: Passive View to design the UI proce
Page 15 and 16: Avoid tight coupling to objects in
Page 17 and 18: is included in exception messages,
Page 19 and 20: To implement navigation between Vie
Page 21 and 22: concurrency. However, do not make t
Page 23 and 24: Quality Attributes The following gu
Page 25: • Scenarios. Application scenario
Page 29 and 30: data entry with forms in an occasio
Page 31 and 32: Scalability Security Supportability
Page 33 and 34: • How to determine an expiration
Page 35 and 36: PART I Fundamentals In This Part:
Page 37 and 38: • What is architecturally signifi
Page 39 and 40: • Architecture should expose the
Page 41 and 42: performance or usability. Analyze a
Page 43 and 44: to make sure you get the big decisi
Page 45 and 46: • Market Maturity. Take advantage
Page 47 and 48: environmental factors. These factor
Page 49 and 50: Chapter 2 - .NET Platform Overview
Page 51 and 52: Data Access The .NET platform provi
Page 53 and 54: of Windows Workflow Foundation (WF)
Page 55 and 56: Additional Resources For more infor
Page 57 and 58: When developing a mobile applicatio
Page 59 and 60: Service A service is a public inter
Page 61 and 62: Rich Internet Applications (RIA) Ca
Page 63: • Silverlight. You can use Silver
Page 66 and 67: This approach has the advantage of
Page 68 and 69: When you scale your application, yo
Page 70 and 71: • Dynamic (often transient) data
Page 72 and 73: Load Balancing Cluster Install your
Page 74 and 75: Trusted Subsystem In the trusted su
Page 76 and 77:
• Deploy components of the applic
Page 78 and 79:
Chapter 5 - Architectural Styles Ob
Page 80 and 81:
specify the kinds of components you
Page 82 and 83:
Examples Some examples of the clien
Page 84 and 85:
indicates the mode and type of inte
Page 86 and 87:
• It consists of individual appli
Page 88 and 89:
• Use an Active Model pattern wit
Page 90 and 91:
• Abstraction. This allows you to
Page 92 and 93:
• Boundaries are Explicit. Operat
Page 94 and 95:
• You want improved testability a
Page 96 and 97:
Chapter 6 - Quality Attributes Obje
Page 98 and 99:
Key Techniques • Use Network Load
Page 100 and 101:
Key Techniques • Use orchestratio
Page 102 and 103:
• Consider logging and auditing i
Page 104 and 105:
Reliability The application should
Page 106 and 107:
• Consider locating layers on the
Page 108 and 109:
Testability The application must be
Page 110 and 111:
Key Techniques • Spend time to un
Page 112 and 113:
Presentation, Business, and Data Se
Page 114 and 115:
themselves, and allows you to reuse
Page 116 and 117:
The following section describes the
Page 118 and 119:
Business Entities used by Data and
Page 120 and 121:
Client Tier Database Tier Client Da
Page 122 and 123:
PART II Design In This Part: Desig
Page 124 and 125:
Core Architecture Design Activities
Page 126 and 127:
Service (QoS) attributes such as se
Page 128 and 129:
You can host your application's bus
Page 130 and 131:
• You want to model the applicati
Page 132 and 133:
Testability Usability possible to m
Page 134 and 135:
Workflow How to sanitize output. Ho
Page 136 and 137:
Architecture and Design Objectives
Page 138 and 139:
• Each component or module should
Page 140 and 141:
Communication Composition Concurren
Page 142 and 143:
• Use a trusted sub-system wherev
Page 144 and 145:
When designing concurrency and tran
Page 146 and 147:
entity design, the data access laye
Page 148 and 149:
When designing a state management m
Page 150 and 151:
Composition Concurrency and Transac
Page 152 and 153:
• Page Cache -Use a page cache to
Page 154 and 155:
Chapter 10 - Designing Services Obj
Page 156 and 157:
data layer can also include helpers
Page 158 and 159:
General • Design coarse-grained o
Page 160 and 161:
• Consider security requirements
Page 162 and 163:
Additional Resources • For more i
Page 164 and 165:
inary serialization because it is f
Page 166 and 167:
• You can return data in several
Page 168 and 169:
• When using XML for passing data
Page 170 and 171:
• Consider the impact of security
Page 172 and 173:
SOAP This approach serializes data
Page 174 and 175:
Chapter 12 - Presentation Layer Gui
Page 176 and 177:
Composition Exception Management In
Page 178 and 179:
Composition Consider whether your a
Page 180 and 181:
When designing your navigation stra
Page 182 and 183:
• Where the UI requires complex w
Page 184 and 185:
• If you are using WPF, consider
Page 186 and 187:
Chapter 13 - Business Layers Guidel
Page 188 and 189:
• Choose appropriate transaction
Page 190 and 191:
Logging and Instrumentation Service
Page 192 and 193:
When designing business entities, c
Page 194 and 195:
• Design an appropriate notificat
Page 196 and 197:
Pattern Map Category Authentication
Page 198 and 199:
For more information on design patt
Page 200 and 201:
especially designed to maximize dat
Page 202 and 203:
• Consider security risks. The da
Page 204 and 205:
• Batch largely similar queries f
Page 206 and 207:
• When it is necessary to dynamic
Page 208 and 209:
Manageability Considerations When d
Page 210 and 211:
Pattern Map Category Patterns Gener
Page 212 and 213:
Chapter 15 - Service Layer Guidelin
Page 214 and 215:
• Use a layered approach to desig
Page 216 and 217:
• Set appropriate access permissi
Page 218 and 219:
• Determine relevant patterns for
Page 220 and 221:
• Consider implement caching, map
Page 222 and 223:
Message Transformation REST Service
Page 224 and 225:
PART IV Quality Attributes In This
Page 226 and 227:
Key Activities in the Life Cycle Th
Page 228 and 229:
Separate your performance concerns
Page 230 and 231:
• Consider designing coarse-grain
Page 232 and 233:
• Design for high cohesion. • P
Page 234 and 235:
patterns & practices Security Engin
Page 236 and 237:
Category Auditing and Logging Authe
Page 238 and 239:
permissions required to access. •
Page 240 and 241:
and is not an upstream user of the
Page 242 and 243:
Chapter 18 - Mobile Applications Ob
Page 244 and 245:
Caching Communication Configuration
Page 246 and 247:
Porting Synchronization UI Validati
Page 248 and 249:
You must deal with both the shutdow
Page 250 and 251:
• If your application must access
Page 252 and 253:
• Do not use exceptions to contro
Page 254 and 255:
Synchronization When designing sync
Page 256 and 257:
Key Patterns • Application Contro
Page 258 and 259:
Office Business Applications (OBA)
Page 260 and 261:
numbers, or custom account numbers
Page 262 and 263:
• Create LOB document templates f
Page 264 and 265:
Figure 4- The Direct Integration Pa
Page 266 and 267:
Figure - The Embedded LOB Informati
Page 268 and 269:
the open order status part, which i
Page 270 and 271:
The Collaboration pattern uses MOSS
Page 272 and 273:
Additional Resources For more infor
Page 274 and 275:
Key Scenarios Rich Client Applicati
Page 276 and 277:
• Data access logic components. D
Page 278 and 279:
Communication Rich Clients can comm
Page 280 and 281:
in memory. Consider encrypting stor
Page 282 and 283:
must be able to cache this data, ac
Page 284 and 285:
• Ensure that you implement featu
Page 286 and 287:
identify each risk and assign a rel
Page 288 and 289:
Approaches for handling data concur
Page 290 and 291:
Client-Server With a client-server
Page 292 and 293:
Pattern Map Category Business Layer
Page 294 and 295:
Additional Resources • For more i
Page 296 and 297:
Design Considerations • Consider
Page 298 and 299:
calls. Logging • Failing to log c
Page 300 and 301:
When designing a communication stra
Page 302 and 303:
• Consider the limitations of the
Page 304 and 305:
State Management You can store appl
Page 306 and 307:
• The isolated storage mechanism
Page 308 and 309:
Consider the following guidelines w
Page 310 and 311:
• Windows Communication Foundatio
Page 312 and 313:
Common Services Scenarios Services
Page 314 and 315:
• Ensure that the service can det
Page 316 and 317:
Authentication The design of an eff
Page 318 and 319:
When designing message endpoints, c
Page 320 and 321:
• Decide if multiple views should
Page 322 and 323:
• The data layer should be deploy
Page 324 and 325:
Data Consistency Exception Handling
Page 326 and 327:
Chapter 23 - SharePoint LOB Applica
Page 328 and 329:
interfaces by invoking the Web serv
Page 330 and 331:
• Do not use SharePoint Document
Page 332 and 333:
When developing BDC applications, c
Page 334 and 335:
Deployment Considerations When desi
Page 336 and 337:
Chapter 24 - Web Application Archet
Page 338 and 339:
determine if communication across p
Page 340 and 341:
• Use a platform-supported authen
Page 342 and 343:
users deny their actions. Log files
Page 344 and 345:
• Consider the serialization requ
Page 346 and 347:
• Design a strategy for formattin
Page 348 and 349:
• Consider the use of input and d
Page 350 and 351:
Consider the following guidelines w
Page 352 and 353:
• Template View - Implement a com
Page 354 and 355:
Exception Handling Application Bloc
Page 356 and 357:
• Console application. • Window
Page 358 and 359:
Exception Handling Application Bloc
Page 360 and 361:
The Policy Injection Application Bl
Page 362 and 363:
• You need to increase flexibilit
Page 364 and 365:
Cheat Sheet: patterns & practices C
Page 366 and 367:
Archived Guides Patterns Reference
Page 368 and 369:
Integration Enterprise Solution Pat
Page 370 and 371:
Cheat Sheet: patterns & practices P
Page 372 and 373:
presentation model. The view class
Page 374 and 375:
eturns a reference to the instance.
Page 376 and 377:
shared infrastructure for sending b
Page 378:
• Message Validator. The message
show all

Application Architecture Guide 2.0 BETA 1 - Willy .Net

Create successful ePaper yourself

Delete template?

Save as template?