.NET Architecture for Enterprises

3,182 views
3,036 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,182
On SlideShare
0
From Embeds
0
Number of Embeds
123
Actions
Shares
0
Downloads
184
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

.NET Architecture for Enterprises

  1. 1. .NET Architecture for Enterprises Wade Wegner Architect, Microsoft Corporation wade.wegner@microsoft.com http://www.architectingwith.net/
  2. 2. First, a story …
  3. 3. First, a story … p e r s o n^ l a
  4. 4. There once was a developer …
  5. 5. … who really enjoyed coding …
  6. 6. Window Server Tibco Apache Web Services Python SQL Server HTML .NET SOA JavaScript BizTalk AS/400 Oracle IIS
  7. 7. … and then one day …
  8. 8. … through no fault of his own …
  9. 9. … someone called him an architect.
  10. 10. How did this happen?
  11. 11. Was he suddenly a different person?
  12. 12. Did he now need to care about different things?
  13. 13. Goals
  14. 14. Goals Leave with a better understanding of architecture
  15. 15. Goals Leave with a better understanding of architecture s o f t w a ^r e
  16. 16. Goals Understand the practical aspects of architecture in .NET
  17. 17. What is architecture?
  18. 18. Why should I care?
  19. 19. How is software architecture different?
  20. 20. Determining how to do something
  21. 21. Making expensive and hard-to-change decisions
  22. 22. Who is the architect?
  23. 23. Are there different types of architects?
  24. 24. Are architects project managers?
  25. 25. Should architects write code?
  26. 26. Do architects just focus on abstractions?
  27. 27. Poor software typically has one of two causes …
  28. 28. … insufficient skills.
  29. 29. … contradictory and ambiguous requirements.
  30. 30. Anyone can write code that just works.
  31. 31. Our goal should be …
  32. 32. … to write good code that works.
  33. 33. Why?
  34. 34. For poorly written code “that just works”…
  35. 35. … maintenance is expensive
  36. 36. … maintenance is frustrating
  37. 37. … maintenance is time consuming
  38. 38. How do we write good code that works?
  39. 39. Tenets of Structured Design
  40. 40. Tenets of Structured Design Cohesion
  41. 41. Tenets of Structured Design Coupling
  42. 42. Tenets of Structured Design Low coupling & High cohesion
  43. 43. Separation of Concerns
  44. 44. Separation of Concerns Identifying the concerns
  45. 45. Separation of Concerns Modularity
  46. 46. Separation of Concerns Information hiding
  47. 47. So, what are some principles that make this easier?
  48. 48. Principles Find Pertinent Objects First
  49. 49. 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
  50. 50. Principles Favor Low Coupling
  51. 51. Principles Program to an interface, not an implementation Favor Low Coupling
  52. 52. Principles Favor Code Reuse
  53. 53. This is great, we know this … so, what else is there?
  54. 54. Advanced Principles Open/Closed Principle
  55. 55. Advanced Principles Liskov’s Substitution Principle
  56. 56. Advanced Principles Dependency Inversion Principle
  57. 57. Advanced Principles public class Foo { IDoSomething _doSomething = null; public Foo(IDoSomething doSomething) { _doSomething = doSomething; } } Dependency Inversion Principle
  58. 58. Patterns
  59. 59. Patterns Design Patterns
  60. 60. Patterns Architectural Patterns
  61. 61. Patterns Antipatterns
  62. 62. Patterns are not …
  63. 63. Patterns are not … … a verb
  64. 64. Patterns are not … … superhuman
  65. 65. Patterns are not … … inherently good nor evil
  66. 66. Testability & Security
  67. 67. Testability
  68. 68. Testability Software Testing
  69. 69. Testability Software Contracts
  70. 70. Testability Unit Testing
  71. 71. Testability Dealing with Dependencies
  72. 72. Testability Fakes to Mocks
  73. 73. Security
  74. 74. Security Security as a requirement
  75. 75. Security Security Development Lifecycle
  76. 76. Security Development Lifecycle Layering
  77. 77. Security Development Lifecycle Componentization
  78. 78. Security Development Lifecycle Roles
  79. 79. Security Threat models
  80. 80. Okay, is this it?
  81. 81. Interesting, but abstract
  82. 82. How does this help me design my system?
  83. 83. Let’s look at the common layers of any system …
  84. 84. The Business Layer
  85. 85. The Service Layer
  86. 86. The Data Access Layer
  87. 87. The Presentation Layer
  88. 88. The Business Layer
  89. 89. The Business Layer What is it?
  90. 90. The Business Layer Domain’s Object Model
  91. 91. The Business Layer Domain Entities
  92. 92. The Business Layer Business Rules
  93. 93. The Business Layer Validation
  94. 94. The Business Layer Business Process & Workflow
  95. 95. The Business Layer Where do you deploy it?
  96. 96. The Business Layer The Gray Areas
  97. 97. The Business Layer – Gray Areas Data Formatting
  98. 98. The Business Layer – Gray Areas CRUD
  99. 99. The Business Layer – Gray Areas Stored Procedures
  100. 100. The Business Layer Patterns
  101. 101. The Business Layer The Transaction Script Pattern
  102. 102. The Business Layer The Table Module Pattern
  103. 103. The Business Layer The Active Record Pattern
  104. 104. The Business Layer The Domain Model Pattern
  105. 105. The Service Layer
  106. 106. The Service Layer What is it?
  107. 107. The Service Layer What’s service orientation?
  108. 108. What about SOA?
  109. 109. The Services Layer Service-Oriented Architecture
  110. 110. The Services Layer Tenets of SOA
  111. 111. Tenets of SOA Boundaries Are Explicit
  112. 112. Tenets of SOA Services Are Autonomous
  113. 113. Tenets of SOA Use Contracts, Not Classes
  114. 114. Tenets of SOA Compatibility Is Based on Policy
  115. 115. What SOA is not …
  116. 116. SOA is not … … a revolution
  117. 117. SOA is not … … a technology
  118. 118. SOA is not … … a web service
  119. 119. SOA is not … … a goal
  120. 120. The Data Access Layer
  121. 121. The Data Access Layer What is it?
  122. 122. The Data Access Layer Requirements
  123. 123. DAL: Requirements Database Independence
  124. 124. DAL: Requirements Configurable as a Plug-in
  125. 125. DAL: Requirements Persisting the Application’s Object Model
  126. 126. The Data Access Layer Responsibilities
  127. 127. DAL: Responsibilities CRUD services
  128. 128. DAL: Responsibilities Query services
  129. 129. DAL: Responsibilities Transactions
  130. 130. DAL: Responsibilities Concurrency
  131. 131. The Data Access Layer Separated Interface Pattern
  132. 132. The Data Access Layer The Plugin Pattern
  133. 133. The Data Access Layer Should you write your own DAL?
  134. 134. The Data Access Layer O/RMs
  135. 135. LINQ-to-SQL Genome EntitySpaces Entity Framework LLBLGen Pro NHibernate
  136. 136. The Data Access Layer Using an O/RM Tool
  137. 137. The Data Access Layer Stored Procedures?
  138. 138. DAL: Stored Procedure Myth #1 SPs are faster than SQL code
  139. 139. DAL: Stored Procedure Myth #2 SPs are more secure than SQL code
  140. 140. DAL: Stored Procedure Myth #3 SPs can be used to fend off SQL injection
  141. 141. DAL: Stored Procedure Myth #4 SPs can be used to reduce brittleness of SQL code
  142. 142. Stop! What are you saying?
  143. 143. Do we still need DBAs?
  144. 144. The Presentation Layer
  145. 145. The Presentation Layer Responsibilities
  146. 146. PL: Responsibilities Validation? Formatting? Styling? Usability?
  147. 147. PL: Responsibilities Independence from graphics
  148. 148. PL: Responsibilities Independence from UI Technology
  149. 149. PL: Responsibilities Testability
  150. 150. PL: Responsibilities Independence from data model
  151. 151. The Presentation Layer Patterns
  152. 152. PL: Patterns Model-View-Controller (MVC)
  153. 153. PL: Patterns Model-View-Presenter (MVP)
  154. 154. The Presentation Layer How do I choose a pattern?
  155. 155. Summary
  156. 156. Summary Defined Architecture
  157. 157. Summary Described Architects
  158. 158. Summary Maintainability
  159. 159. Summary Low coupling & high cohesion
  160. 160. Summary Principles of software architecture
  161. 161. Summary Design patterns
  162. 162. Summary Architecture patterns & antipatterns
  163. 163. Summary Testability & Security
  164. 164. Summary The Business Layer
  165. 165. Summary The Services Layer
  166. 166. Summary The Data Access Layer
  167. 167. Summary The Presentation Layer
  168. 168. Closing thoughts …
  169. 169. Closing thoughts … “It” depends
  170. 170. Closing thoughts … Requirements
  171. 171. Closing thoughts … Reuse is a nice side effect
  172. 172. Closing thoughts … Separation of Concerns
  173. 173. Closing thoughts … Maintainability
  174. 174. Closing thoughts … Don’t trust your users
  175. 175. Closing thoughts … Security and testability by design
  176. 176. 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.

×