pragmatic architecture in .net

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