.NET Architecture
for Enterprises
Wade Wegner
Architect, Microsoft Corporation
wade.wegner@microsoft.com
http://www.architectingwith.net/

First, a story …

First, a story …
p e r s o n^ l
a

There once was a developer …

… who really enjoyed coding …

Window Server
Tibco
Apache
Web Services
Python
SQL Server HTML
.NET
SOA
JavaScript BizTalk
AS/400 Oracle
IIS

… and then one day …

… through no fault of his own …

… someone called him an architect.

How did this happen?

Was he suddenly a
different person?

Did he now need to care
about different things?

Goals

Goals
Leave with a better understanding
of architecture

Goals
Leave with a better understanding
of architecture
s o f t w a ^r e

Goals
Understand the practical aspects
of architecture in .NET

What is architecture?

Why should I care?

How is software architecture
different?

Determining how to do something

Making expensive and
hard-to-change decisions

Who is the architect?

Are there different types
of architects?

Are architects project managers?

Should architects write code?

Do architects just focus
on abstractions?

Poor software typically
has one of two causes …

… insufficient skills.

… contradictory and ambiguous
requirements.

Anyone can write code
that just works.

Our goal should be …

… to write good code
that works.

Why?

For poorly written code
“that just works”…

… maintenance is expensive

… maintenance is frustrating

… maintenance is time consuming

How do we write good code
that works?

Tenets of Structured Design

Tenets of Structured Design
Cohesion

Tenets of Structured Design
Coupling

Tenets of Structured Design
Low coupling &
High cohesion

Separation of Concerns

Separation of Concerns
Identifying the concerns

Separation of Concerns
Modularity

Separation of Concerns
Information hiding

So, what are some principles that
make this easier?

Principles
Find Pertinent Objects First

Principles
To view all orders placed by a customer, the
user indicates the customer ID. The program
displays an error message if the customer does
not exist. If the customer exists, the program
displays name, address, date of birth, and all
outstanding orders. For each order, the
program gets ID, date, and all order items.
Find Pertinent Objects First

Principles
Favor Low Coupling

Principles
Program to an interface, not an
implementation
Favor Low Coupling

Principles
Favor Code Reuse

This is great, we know this …
so, what else is there?

Advanced Principles
Open/Closed Principle

Advanced Principles
Liskov’s Substitution Principle

Advanced Principles
Dependency Inversion Principle

Advanced Principles
public class Foo
{
IDoSomething _doSomething = null;
public Foo(IDoSomething doSomething)
{
_doSomething = doSomething;
}
}
Dependency Inversion Principle

Patterns

Patterns
Design Patterns

Patterns
Architectural Patterns

Patterns
Antipatterns

Patterns are not …

Patterns are not …
… a verb

Patterns are not …
… superhuman

Patterns are not …
… inherently good nor evil

Testability & Security

Testability

Testability
Software Testing

Testability
Software Contracts

Testability
Unit Testing

Testability
Dealing with Dependencies

Testability
Fakes to Mocks

Security

Security
Security as a requirement

Security
Security Development Lifecycle

Security Development Lifecycle
Layering

Security Development Lifecycle
Componentization

Security Development Lifecycle
Roles

Security
Threat models

Okay, is this it?

Interesting, but abstract

How does this help me design my
system?

Let’s look at the common layers of any
system …

The Business Layer

The Service Layer

The Data Access Layer

The Presentation Layer

The Business Layer

The Business Layer
What is it?

The Business Layer
Domain’s Object Model

The Business Layer
Domain Entities

The Business Layer
Business Rules

The Business Layer
Validation

The Business Layer
Business Process & Workflow

The Business Layer
Where do you deploy it?

The Business Layer
The Gray Areas

The Business Layer – Gray Areas
Data Formatting

The Business Layer – Gray Areas
CRUD

The Business Layer – Gray Areas
Stored Procedures

The Business Layer
Patterns

The Business Layer
The Transaction Script Pattern

The Business Layer
The Table Module Pattern

The Business Layer
The Active Record Pattern

The Business Layer
The Domain Model Pattern

The Service Layer

The Service Layer
What is it?

The Service Layer
What’s service orientation?

What about SOA?

The Services Layer
Service-Oriented Architecture

The Services Layer
Tenets of SOA

Tenets of SOA
Boundaries Are Explicit

Tenets of SOA
Services Are Autonomous

Tenets of SOA
Use Contracts, Not Classes

Tenets of SOA
Compatibility Is Based on Policy

What SOA is not …

SOA is not …
… a revolution

SOA is not …
… a technology

SOA is not …
… a web service

SOA is not …
… a goal

The Data Access Layer

The Data Access Layer
What is it?

The Data Access Layer
Requirements

DAL: Requirements
Database Independence

DAL: Requirements
Configurable as a Plug-in

DAL: Requirements
Persisting the Application’s
Object Model

The Data Access Layer
Responsibilities

DAL: Responsibilities
CRUD services

DAL: Responsibilities
Query services

DAL: Responsibilities
Transactions

DAL: Responsibilities
Concurrency

The Data Access Layer
Separated Interface Pattern

The Data Access Layer
The Plugin Pattern

The Data Access Layer
Should you write your own DAL?

The Data Access Layer
O/RMs

LINQ-to-SQL
Genome
EntitySpaces
Entity Framework
LLBLGen Pro
NHibernate

The Data Access Layer
Using an O/RM Tool

The Data Access Layer
Stored Procedures?

DAL: Stored Procedure Myth #1
SPs are faster than SQL code

DAL: Stored Procedure Myth #2
SPs are more secure than SQL code

DAL: Stored Procedure Myth #3
SPs can be used to fend off SQL
injection

DAL: Stored Procedure Myth #4
SPs can be used to reduce brittleness
of SQL code

Stop! What are you saying?

Do we still need DBAs?

The Presentation Layer

The Presentation Layer
Responsibilities

PL: Responsibilities
Validation?
Formatting?
Styling?
Usability?

PL: Responsibilities
Independence from graphics

PL: Responsibilities
Independence from UI Technology

PL: Responsibilities
Testability

PL: Responsibilities
Independence from data model

The Presentation Layer
Patterns

PL: Patterns
Model-View-Controller (MVC)

PL: Patterns
Model-View-Presenter (MVP)

The Presentation Layer
How do I choose a pattern?

Summary

Summary
Defined Architecture

Summary
Described Architects

Summary
Maintainability

Summary
Low coupling & high cohesion

Summary
Principles of software architecture

Summary
Design patterns

Summary
Architecture patterns & antipatterns

Summary
Testability & Security

Summary
The Business Layer

Summary
The Services Layer

Summary
The Data Access Layer

Summary
The Presentation Layer

Closing thoughts …

Closing thoughts …
“It” depends

Closing thoughts …
Requirements

Closing thoughts …
Reuse is a nice side effect

Closing thoughts …
Separation of Concerns

Closing thoughts …
Maintainability

Closing thoughts …
Don’t trust your users

Closing thoughts …
Security and testability by design

wade.wegner@microsoft.com
http://architectingwith.net
© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.