.NET Architecture for Enterprises
Upcoming SlideShare
Loading in...5

.NET Architecture for Enterprises






Total Views
Views on SlideShare
Embed Views



6 Embeds 123

http://blog.wadewegner.com 60
http://www.architectingwith.net 26
http://www.wadewegner.com 26
http://www.linkedin.com 7
http://www.slideshare.net 3
http://feeds2.feedburner.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

.NET Architecture for Enterprises .NET Architecture for Enterprises Presentation Transcript

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