View
1.171
Download
1
Category
Preview:
DESCRIPTION
An architect’s job is to reduce complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? We’ll learn when abstractions are justified and discuss how to structure applications so they’re maintainable, scalable, and testable. We’ll make sure everyone is comfy with the core jargon like N-Teir, separation of concerns, and loose coupling. Then we’ll dive into various patterns for implementing the three common layers: data access, business logic, and presentation. You’ll learn when table module, active record, DDD, and ORMs make sense and walk away with the tools to better evaluate and justify complexity. We’ll focus on the value of keeping things simple whenever we can. Examples are presented in C# in Visual Studio but developers in Java, PHP, and other C-like languages should be able to follow right along.
Citation preview
Pragmatic Architecture in .NETCory House
@housecor | bitnative.com
The problem.
X is good It Depends
Three Simple Goals:
1. Cost vs benefit2. Contrast extremes3. Review our options in .NET
Why?
Save money.Save effort.Save time.
Why Not?
To improve my resume’.To challenge myself.To experiment.
Assumptions
1. Web based2. RDBMS3. Enterprise line of business app
Astronaut Assessment
We must use <shiny new technology> for this!
Reinvent the wheel100% test coverageNever ORMAlways code to an interfaceUse all the patternsResume Driven Development
Consider Simplicity
1. Do simplest thing that could possibly work2. Lean / Agile principles3. YAGNI4. 80/20 Rule
Consider Complexity
• Unit Testing• Coding to an interface• SOA• Rich Domain Model• Layered N-teir architecture
Which is better?
Tightly Coupled
No Tests
No Layers
No API
Coded to Interfaces
100% Test coverage
Rich Domain Model
Service Oriented
It depends.
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
Work expands to fill available time.Parkinson’s Law
Agile Estimation: Flex one.
Quality
Date Cost
Features*ArchitectureReusePerformanceSecurityTestingScalabilityDocumentation
* Fat chance
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.
Q: Is debt bad?
Later
Now
A: Is the deadline hard?
Hard vs Soft Deadlines
Trade showPublished advertisingX-team dependencies1st to market or deadNetwork effects
Single loud customerWAGSalesman misspokeMS Project said so
Perfect architecture? Who cares.
FacebookTwitterStackOverflow
The problem is getting people to care.
We’re paid for solutions, not code.
Unit Testing – Insurance– Investment in the future (ease of maint)– Potential long-term cost in complexity/manpower
Enough Theory…
Let’s get geeky.
Presentation
Service
Domain
Data
Web Forms vs MVCJavaScript, CSS, jQuery, Knockout, Angular, IoC
Web API, WCF, ASMX, ServiceStack or POCOs
C#, VB.Net
Entity Framework, nHibernate, LLBLGen, Dapper, ADO.Net
UI
API
Business Logic (BLL)
Data Access (DAL)
Presentation
Service
Domain
Persistence
Layers vs Tiers
Logical Physical
Tiers
ScalabilitySecurityAbstract complexityMinimize dependencesReusable
Performance costIncreased complexity
Layers
Separate concernsAid understandingAbstract complexitySupport testingMinimize dependencesStandardizeEnable reuse
LeakMore code
Small app?methods = layers.
ORM honors DRY
1. Database 2. Class property3. Select statements4. Insert statements5. Update statements6. Delete statements7. SQL marshalling code
1. Database 2. Class property3. .hbm.xml file
When ORM?
Go for it:• DRY = faster
development• Speedier changes• RDBMS agnostic• Type safe interface• Avoid writing SQL• SQL Injection protection• Security, performance,
caching, mapping OOTB
Pass:• Lose control over SQL• DBAs lose control• Security concerns• Performance penalty
SOA
Heterogeneous systemsAutonomous ReusableFormal
Performance hitRisky changesBoth sides must test
Architectural LevelsL1 Simplest
thingL2 Somewhere
in between
L3 Every tool in the shed
Level 1
Presentation
Domain & Persistence
Web Forms
Active Record Pattern Linq-2-SQL, Subsonic, Castle ActiveRecord
Active Record
Presentation
Domain
Data
Active Record
Customer Address Purchase
Customer Address Purchase
DB Tables
ClassesOne instance = One row
Active Record
Simple & obviousSpeedy dev and changesCompliments CRUD appsGood for simple domainNo OR mismatchHonors YAGNI
Rigid: Domain model = DBLeads to God objectLow cohesion: Breaks SRPHard to testTricky transactionsRepository pattern = pain
Level 3
Presentation
Service
Domain
Persistence
ASP.Net MVC, Knockout/Angular
Repository Pattern nHibernate, EF POCOs, Dapper
DDD with POCOs
WCF, ServiceStack
Domain Model
It’s all about the objects.
Domain Model
Customer Address Purchase
Customer with list of addresses
Purchase
DB Tables
ClassesNote OR Mismatch
Business Layer Patterns: Domain Model
Complex business domainLeverage design patternsSpeak business languageAbstracts ugly DB schemaLarge teamReusable
Learning curveTime-consuming designLong-term commitmentDB mapping overhead
Level 3 SummaryTestableManage object lifecycleAOP via dynamic proxiesSwappable UI or DALSpeaks in business languageLeverage design patterns
Slower initial devLarger initial dev costLearning curveMore places to changeSenior developers
Bottom Line: L1 vs L3
Points to Add a Feature
Level 11. UI2. DB 3. Implement BL (in AR class)4. Regen DAL
Level 31. UI2. DB3. Implement BL in POCO4. Update/create interface5. Update IoC bootstrap6. Update DB mapping7. Update/Add service call8. Add/update tests
Choice by Complexity
Level 3
Level 2Level 1
Effort to enhance
Application Complexity
Architectural LevelsLevel 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
Architecture Selection
MVPJunior teamSmall teamSimple DomainTight timelineThrowawayNo security concernsLittle chance for reuse
Flagship productSenior TeamLarge Team
Complex domainFlexible timeline
Long-termSecurity matters
Other apps could reuse
L1 L3
Reading
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.
Cory House
@housecor | bitnative.com
Recommended