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.
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
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
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
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
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
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
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
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
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.
Notes de l'éditeur
Unit testingDomain Driven DesignSOAEvery abstraction has a cost. Know what you're getting and giving.
not games, embedded software)
http://www.xprogramming.com/Practices/PracSimplest.htmlGet 80 of the benefit from 20% of the features.
Note: Rarely is scope decreased, deadlines moved, or manpower added.
Often deadlines are arbitrary – you estimate so executives know about when something will be released. Real deadline
Facebook uses PHPTwitterStackOverflow - used Linq-2-SQL (Active record pattern). Now #85 globallyThe problem is getting people to care
Peformance Cost: Translation. Often offset by performance tuning, via encapsulation (e.g. caching queries)
Reusable: HTTP, Telnet, SSH use TCP/IPLeaky: Update all layers to add UI fieldPerformance Cost: Translation. Often offset by performance tuning, via encapsulation (e.g. caching queries)
Escalate to separate classes and modules as complexity justifies
On the other hand, you know how it works. You can debug it. It's all right there in your own persistence layer, not buried in the bowels of a 3rd party tool.
Note under pass - Sprocs can be used to please DBAs, but lose are required by DBAs (mitigates benefits)