Application Architecture Guide 2.0 BETA 1 - Willy .Net

presentation, business, and data access layers. This helps you to create maintainable,
scalable code and allows you to monitor and optimize the performance of each layer
separately. Use abstraction to implement loose coupling between layers. This can be
accomplished by defining interface components, such as a façade with well-known inputs
and outputs that translates requests into a format understood by components within the
layer. In addition, you can use interface types or abstract base classes to define a shared
abstraction that must be implemented by interface components. When designing a Web
application, consider using techniques such as caching and output buffering to reduce
round trips between the browser and the Web server, and between the Web server and
downstream servers. Avoid blocking during long-running tasks. If you have long-running or
blocking operations, consider using an asynchronous approach to allow the Web server to
process other incoming requests. Design your application to authenticate users whenever
they cross a trust boundary; for example, when accessing a remote business layer from your
presentation layer. Consider using a trusted sub-system for authentication across trust
boundaries. This is particularly useful when accessing a data layer that connects to a
database. When using a trusted sub-system, consider flowing the user’s identity with the
call in order to support auditing and non-repudiation. Whenever you must pass sensitive
data such as a password or authentication cookie across the network, consider encrypting
and signing the data or using a secure transport mechanism such as SSL. Design to run your
Web application using a least-privilege account. If an attacker manages to take control of a
process, the process identity should have restricted access to the file system and other
system resources in order to limit the possible damage.
Architecture Frame
The following guidelines will help you to understand the fundamental cross cutting factors
when designing your chosen application type.
• How to design your exception management strategy
Exceptions can be expensive. Do not use exceptions to implement application logic. Use
structured exception handling to build robust code, and use exceptions instead of error
codes where possible. While exceptions do carry a performance penalty, they are more
expressive and less error prone than error codes. Write code that avoids unnecessary
exceptions. In other words, adopt a defensive coding strategy where checks are made prior
to accessing an object or component. Use finally blocks to guarantee that resources are
cleaned up when exceptions occur. For example, close your database connections in a
finally block. You do not need a catch block with a finally block. Finally blocks that are not
related to exceptions are inexpensive. Do not reveal internal system or application details,
such as stack traces, SQL statement fragments, and so on. Ensure that this type of
information is not allowed to propagate to the end user or beyond your current trust
boundary. Fail securely in the event of an exception, and make sure your application denies
access and is not left in an insecure state. Do not log sensitive or private data such as
passwords, which could be compromised. When you log or report exceptions, if user input
16