The document discusses pragmatic architecture approaches in .NET. It outlines three levels of architecture - Level 1 using simple patterns like active record, Level 2 with some separation of concerns, and Level 3 using domain-driven design and other complex patterns. The key points are that the simplest approach that could work is best, context matters, and best practices have both benefits and costs to consider for the project.

1. Pragmatic Architecture in .NET
Cory House
@housecor | bitnative.com

2. The problem.

3. X is good It Depends

4. Three Simple Goals:
1. Cost vs benefit
2. Contrast extremes
3. Review our options in .NET

5. Why?
Save money.
Save effort.
Save time.

6. Why Not?
To improve my resume’.
To challenge myself.
To experiment.

7. Assumptions
1. Web based
2. RDBMS
3. Enterprise line of business app

8. Astronaut Assessment
We must use <shiny new technology> for this!
Reinvent the wheel
100% test coverage
Never ORM
Always code to an interface
Use all the patterns
Resume Driven Development

9. Consider Simplicity
1. Do simplest thing that could possibly work
2. Lean / Agile principles
3. YAGNI
4. 80/20 Rule

10. Consider Complexity
• Unit Testing
• Coding to an interface
• SOA
• Rich Domain Model
• Layered N-teir architecture

11. Which is better?
Tightly Coupled
No Tests
No Layers
No API
Coded to Interfaces
100% Test coverage
Rich Domain Model
Service Oriented

12. It depends.

13. What if I said…
• $250k over budget
• Customers hated it, or worse, ignored it
• Idea didn’t pan out
• Project funding dried up
• 1 month late = worthless

14. Work expands to fill available time.
Parkinson’s Law

15. Agile Estimation: Flex one.
Quality
Date Cost
Features*
Architecture
Reuse
Performance
Security
Testing
Scalability
Documentation
* Fat chance

16. Quality is reduced to meet deadlines.
Software quality is directly related to deadline sanity.
Deadline and manpower are often a constant.
Thus, software quality is directly related to deadline
sanity.
Quality software requires realistic deadlines.

17. Q: Is debt bad?
Later
Now
A: Is the deadline hard?

18. Hard vs Soft Deadlines
Trade show
Published advertising
X-team dependencies
1st to market or dead
Network effects
Single loud customer
WAG
Salesman misspoke
MS Project said so

19. Perfect architecture? Who cares.
Facebook
Twitter
StackOverflow
The problem is getting people to care.

20. We’re paid for solutions, not code.
Unit Testing
– Insurance
– Investment in the future (ease of maint)
– Potential long-term cost in complexity/manpower

21. Enough Theory…
Let’s get geeky.

22. Presentation
Service
Domain
Data
Web Forms vs MVC
JavaScript, CSS, jQuery, Knockout, Angular, IoC
Web API, WCF, ASMX, ServiceStack or POCOs
C#, VB.Net
Entity Framework, nHibernate, LLBLGen, Dapper, ADO.Net

23. UI
API
Business Logic
(BLL)
Data Access
(DAL)
Presentation
Service
Domain
Persistence

24. Layers vs Tiers
Logical Physical

25. Tiers
Scalability
Security
Abstract complexity
Minimize dependences
Reusable
Performance cost
Increased complexity

26. Layers
Separate concerns
Aid understanding
Abstract complexity
Support testing
Minimize dependences
Standardize
Enable reuse
Leak
More code

27. Small app?
methods = layers.

28. ORM honors DRY
1. Database
2. Class property
3. Select statements
4. Insert statements
5. Update statements
6. Delete statements
7. SQL marshalling code
1. Database
2. Class property
3. .hbm.xml file

29. When ORM?
Go for it:
• DRY = faster development
• Speedier changes
• RDBMS agnostic
• Type safe interface
• Avoid writing SQL
• SQL Injection protection
• Security, performance, ca
ching, mapping OOTB
Pass:
• Lose control over SQL
• DBAs lose control
• Security concerns
• Performance penalty

30. SOA
Heterogeneous systems
Autonomous
Reusable
Formal
Performance hit
Risky changes
Both sides must test

31. Architectural LevelsL1
Simplest
thing
L2
Somewhere
in between
L3
Every tool
in the shed

32. Level 1
Presentation
Domain &
Persistence
Web Forms
Active Record Pattern
Linq-2-SQL, Subsonic, Castle ActiveRecord

33. Active Record
Presentation
Domain
Data

34. Active Record
Customer Address Purchase
Customer Address Purchase
DB Tables
Classes
One instance = One row

35. Active Record
Simple & obvious
Speedy dev and changes
Compliments CRUD apps
Good for simple domain
No OR mismatch
Honors YAGNI
Rigid: Domain model = DB
Leads to God object
Low cohesion: Breaks SRP
Hard to test
Tricky transactions
Repository pattern = pain

36. Level 3
Presentation
Service
Domain
Persistence
ASP.Net MVC, Knockout/Angular
Repository Pattern
nHibernate, EF POCOs, Dapper
DDD with POCOs
WCF, ServiceStack

37. Domain Model
It’s all about the objects.

38. Domain Model
Customer Address Purchase
Customer
with list of addresses
Purchase
DB Tables
Classes
Note OR Mismatch

39. Business Layer Patterns: Domain Model
Complex business domain
Leverage design patterns
Speak business language
Abstracts ugly DB schema
Large team
Reusable
Learning curve
Time-consuming design
Long-term commitment
DB mapping overhead

40. Level 3 Summary
Testable
Manage object lifecycle
AOP via dynamic proxies
Swappable UI or DAL
Speaks in business language
Leverage design patterns
Slower initial dev
Larger initial dev cost
Learning curve
More places to change
Senior developers

41. Bottom Line: L1 vs L3

42. Points to Add a Feature
Level 1
1. UI
2. DB
3. Implement BL (in AR class)
4. Regen DAL
Level 3
1. UI
2. DB
3. Implement BL in POCO
4. Update/create interface
5. Update IoC bootstrap
6. Update DB mapping
7. Update/Add service call
8. Add/update tests

43. Choice by Complexity
Level 3
Level 2Level 1
Effort to
enhance
Application Complexity

44. Architectural Levels
Level 1 Level 2 Level 3
Centralized Data Access ?
Mockable Data Access ?
Central Lifetime Management ?
Separation of Concerns ?
Domain Driven Design ?
Unit Testing Friendly ?
Concurrent Development ?
Service Oriented ?
SOLID ?
SPA friendly ?
Simplest thing/YAGNI

45. Architecture Selection
MVP
Junior team
Small team
Simple Domain
Tight timeline
Throwaway
No security concerns
Little chance for reuse
Flagship product
Senior Team
Large Team
Complex domain
Flexible timeline
Long-term
Security matters
Other apps could reuse

46. Reading

47. Bottom Line
1. Consider the simplest thing that could possibly
work.
2. Context matters. X isn’t good or bad.
3. Best practices have a benefit and cost.