Application Architecture for .NET Applications

Introduction

This Article series helps the .NET developers and architects to design the effective applications on .NET latest technologies. There are so many articles,books on application architecture but it is still challenging for developers to understand best practices, principles for the application design.

This post speaks about the fundamentals concepts of Application Architecture and principles.

What is Application Architecture?

Defining a solution which meets all technical and operational requirements by optimizing performance,security and manageability.

Why Architecture?

Software must built on a solid considerations and failing to meet the key scenarios and understand the design problems will lead to long term consequences. The application needs to address the following concerns .

• How the end user be using your application?
• What about quality attributes security,performance,concurrency, internationalization and configuration.
• What architecture suits for your application now or after it has been deployed?

Goals of Architecture

Application Architecture builds the bridge between business requirements and technical requirements. Good architecture reduces the business risks associated with the solution.

Architecture should consider

• Structure of the system not the implementation details
• User case scenarios
• Concerns of stake holders
• functional and quality requirements

Approach to Architecture

You must determine the type of application that you are building and architecture styles that will be used and cross cutting technologies.

• Identify the type of application
• How the application will be deployed?
• Drill down for architecture styles and technologies
• Considering Quality attributes and cross=cutting concerns.

Application Type

Key part in architecture and design is identifying the type of application.

The application types can be

• Rich Client application designed to run on client PC.
• Rich Internet applications.
• SOA applications designed to support communication between loosely coupled components.
• Smart client applications.

Deployment Strategy

When you design your application you must plan the infrastructure to deploy your application. Your application must accommodate any restrictions that exist in the environment. Identify infrastructure architecture early in the design process.

Architectural Style

Architectural style is set of policies and rules that we used in the component design later that we use in the application.

Examples of architecture styles

1. Client-server
2. Layered architecture
3. MVC
4. SOA

Cross cutting concerns

These concerns are key areas in your design that are not related to any layer in your application.  You must consider the following concerns when you are designing your application.

Authentication Determine how to authenticate users and pass the identities across the layers.

Authorization Ensure proper authorization across the trusted boundary.

Caching Identify what should be cached and where to cache to improve your application’s performance and responsiveness.

Communication Choose appropriate protocols to protect sensitive data passing over the network.

Exception Management Catch exceptions at the boundaries and show meaning full messages to the end users.

Instrumentation and Logging Instrument all business and system-critical events and log sufficient details. Do not log  sensitive information.

 

Software Architecture can be described as structure of system, where system represents the collection of components that accomplish a set of functions. This post explains the key design principles for software architecture.

The above picture shows you  the common application architecture and different components in the system and how they work together.

Design Principles

• Separation of Concerns Break your application into distinct features.
• Prefer composition over inheritance When reusing the functionality use composition over inheritance because inheritance increases the dependency between parent and child classes.
• Don’t Repeat Yourself(DRY) Define only one component for providing specific functionality and should not be duplicated in any other component.

Design Considerations

When designing a application, software architect is to minimize the complexity by separating the design into different areas. For example UI processing components should not include code that directly access a data source, instead it should use data access components to retrieve data.

Authentication

Failure to design a good authentication strategy can leave your application vulnerable to spoofing attacks and session hijacking.

Consider the following guidelines when designing the authentication strategy

• Identify your trust boundaries
• If you have multiple systems with in the application consider using the single sign-on strategy.
• Store the hash of the passwords in the database.
• Enforce the use of strong passwords.

Authorization

Consider the following guidelines when you are designing the authentication strategy

• Protect resources by applying authorization to callers based on their identity.
• Use resource-based authorization for system auditing.

Caching

Caching improves the performance and responsiveness of your application.

• You should use the cache for avoiding network round trips and avoid duplicate processing of data.
• Do not cache the volatile data.
• Do not cache the sensitive data unless you encrypt it.

Communication

It concerns the interaction between components across the layers. When crossing the physical boundaries, you should use message-based communication.

• Build the service interfaces for communication
• Consider using MSMQ to queue messages for later delivery.

Concurrency and Transactions

When designing for concurrency and transactions for accessing the database it is important to identify the concurrency data model that you want to use. The model can be optimistic or pessimistic.

• If you have business-critical operations, consider wrapping them in transactions.
• Use connection-based transactions when accessing a single-data source.
• Updates to shared data should be mutually exclusive, which is accomplished by applying locks.
• Avoid holding locks for longer period.

Configuration Management

• Encrypt sensitive information in configuration store.
• Provide separate administrative interface for editing configuration information.
• Categorize the configuration items into logical sections.

Data Access

Designing a Data Access Layer is important for application maintainability. The Data Access Layer should be responsible for managing connections and executing commands against data source. I also really like virtual offices, we have another business interest in Scotland so used this virtual office service in Glasgow and it just works great, so have a look at those kinds of services.

• Avoid accessing database directly from other layers and should have the data access layer interaction for DB operations.
• Release the DB connections as early as possible.

Exception Management

Good Design of exception-management strategy is important for the reliability of your application.

• Do not catch the internal exceptions unless you can handle them.
• Design a appropriate exception propagation strategy.
• Design a strategy for unhandled exceptions.
• Design a appropriate logging and notification strategy.

Layering

Designing the layers allows you to separate the functionality into different areas of concern.

• Layers should represent the logical grouping of components.
• Components with in a layer should be cohesive means business layer components should provide options only related to application business logic.

Backtrack: http://www.techbubbles.com/softwarearchitecture/application-architecture-for-net-applications-part2/