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

2. First, a story …

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

4. There once was a developer …

5. … who really enjoyed coding …

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

7. … and then one day …

8. … through no fault of his own …

9. … someone called him an architect.

11. How did this happen?

12. Was he suddenly a
different person?

13. Did he now need to care
about different things?

15. Goals

16. Goals
Leave with a better understanding
of architecture

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

18. Goals
Understand the practical aspects
of architecture in .NET

20. What is architecture?

21. Why should I care?

23. How is software architecture
different?

25. Determining how to do something

26. Making expensive and
hard-to-change decisions

27. Who is the architect?

29. Are there different types
of architects?

30. Are architects project managers?

31. Should architects write code?

32. Do architects just focus
on abstractions?

34. Poor software typically
has one of two causes …

35. … insufficient skills.

36. … contradictory and ambiguous
requirements.

37. Anyone can write code
that just works.

39. Our goal should be …

40. … to write good code
that works.

41. Why?

43. For poorly written code
“that just works”…

44. … maintenance is expensive

45. … maintenance is frustrating

46. … maintenance is time consuming

48. How do we write good code
that works?

52. Tenets of Structured Design

53. Tenets of Structured Design
Cohesion

54. Tenets of Structured Design
Coupling

55. Tenets of Structured Design
Low coupling &
High cohesion

57. Separation of Concerns

58. Separation of Concerns
Identifying the concerns

59. Separation of Concerns
Modularity

60. Separation of Concerns
Information hiding

62. So, what are some principles that
make this easier?

63. Principles
Find Pertinent Objects First

64. 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

65. Principles
Favor Low Coupling

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

67. Principles
Favor Code Reuse

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

69. Advanced Principles
Open/Closed Principle

70. Advanced Principles
Liskov’s Substitution Principle

71. Advanced Principles
Dependency Inversion Principle

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

74. Patterns

75. Patterns
Design Patterns

76. Patterns
Architectural Patterns

77. Patterns
Antipatterns

78. Patterns are not …

79. Patterns are not …
… a verb

80. Patterns are not …
… superhuman

81. Patterns are not …
… inherently good nor evil

83. Testability & Security

85. Testability

86. Testability
Software Testing

87. Testability
Software Contracts

88. Testability
Unit Testing

89. Testability
Dealing with Dependencies

90. Testability
Fakes to Mocks

92. Security

93. Security
Security as a requirement

94. Security
Security Development Lifecycle

95. Security Development Lifecycle
Layering

96. Security Development Lifecycle
Componentization

97. Security Development Lifecycle
Roles

98. Security
Threat models

100. Okay, is this it?

101. Interesting, but abstract

102. How does this help me design my
system?

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

105. The Business Layer

106. The Service Layer

107. The Data Access Layer

108. The Presentation Layer

110. The Business Layer

111. The Business Layer
What is it?

112. The Business Layer
Domain’s Object Model

113. The Business Layer
Domain Entities

114. The Business Layer
Business Rules

115. The Business Layer
Validation

116. The Business Layer
Business Process & Workflow

118. The Business Layer
Where do you deploy it?

119. The Business Layer
The Gray Areas

120. The Business Layer – Gray Areas
Data Formatting

121. The Business Layer – Gray Areas
CRUD

122. The Business Layer – Gray Areas
Stored Procedures

124. The Business Layer
Patterns

125. The Business Layer
The Transaction Script Pattern

126. The Business Layer
The Table Module Pattern

127. The Business Layer
The Active Record Pattern

128. The Business Layer
The Domain Model Pattern

130. The Service Layer

131. The Service Layer
What is it?

132. The Service Layer
What’s service orientation?

133. What about SOA?

134. The Services Layer
Service-Oriented Architecture

135. The Services Layer
Tenets of SOA

136. Tenets of SOA
Boundaries Are Explicit

137. Tenets of SOA
Services Are Autonomous

138. Tenets of SOA
Use Contracts, Not Classes

139. Tenets of SOA
Compatibility Is Based on Policy

140. What SOA is not …

141. SOA is not …
… a revolution

142. SOA is not …
… a technology

143. SOA is not …
… a web service

144. SOA is not …
… a goal

146. The Data Access Layer

147. The Data Access Layer
What is it?

148. The Data Access Layer
Requirements

149. DAL: Requirements
Database Independence

150. DAL: Requirements
Configurable as a Plug-in

151. DAL: Requirements
Persisting the Application’s
Object Model

152. The Data Access Layer
Responsibilities

153. DAL: Responsibilities
CRUD services

154. DAL: Responsibilities
Query services

155. DAL: Responsibilities
Transactions

156. DAL: Responsibilities
Concurrency

157. The Data Access Layer
Separated Interface Pattern

158. The Data Access Layer
The Plugin Pattern

160. The Data Access Layer
Should you write your own DAL?

161. The Data Access Layer
O/RMs

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

163. The Data Access Layer
Using an O/RM Tool

164. The Data Access Layer
Stored Procedures?

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

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

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

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

170. Stop! What are you saying?

171. Do we still need DBAs?

174. The Presentation Layer

175. The Presentation Layer
Responsibilities

176. PL: Responsibilities
Validation?
Formatting?
Styling?
Usability?

177. PL: Responsibilities
Independence from graphics

178. PL: Responsibilities
Independence from UI Technology

179. PL: Responsibilities
Testability

180. PL: Responsibilities
Independence from data model

181. The Presentation Layer
Patterns

182. PL: Patterns
Model-View-Controller (MVC)

183. PL: Patterns
Model-View-Presenter (MVP)

184. The Presentation Layer
How do I choose a pattern?

186. Summary

187. Summary
Defined Architecture

188. Summary
Described Architects

189. Summary
Maintainability

190. Summary
Low coupling & high cohesion

191. Summary
Principles of software architecture

192. Summary
Design patterns

193. Summary
Architecture patterns & antipatterns

194. Summary
Testability & Security

195. Summary
The Business Layer

196. Summary
The Services Layer

197. Summary
The Data Access Layer

198. Summary
The Presentation Layer

200. Closing thoughts …

201. Closing thoughts …
“It” depends

202. Closing thoughts …
Requirements

203. Closing thoughts …
Reuse is a nice side effect

204. Closing thoughts …
Separation of Concerns

205. Closing thoughts …
Maintainability

206. Closing thoughts …
Don’t trust your users

207. Closing thoughts …
Security and testability by design

208. 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.