Pragmatic Architecture in .NET
Upcoming SlideShare
Loading in...5

Pragmatic Architecture in .NET



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

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.



Total Views
Views on SlideShare
Embed Views



3 Embeds 297 294 2 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

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
  • Unit testingDomain Driven DesignSOAEvery abstraction has a cost. Know what you're getting and giving.
  • not games, embedded software)
  • 80 of the benefit from 20% of the features.
  • 6 months: Annual trade show, Ad campaign,
  • Quality: Features, Scope, Architecture, Reuse, Performance, Security
  • 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)
  • Each object owns the logic that is relevant to its piece.
  • UseDataMapper pattern to resolve variant relational object schemas
  • Insert chart from pg 29Note: Not mutually exclusive. Can use each as needed in diff contexts.
  • .Net architecturePOEAADDD

Pragmatic Architecture in .NET Pragmatic Architecture in .NET Presentation Transcript

  • Pragmatic Architecture in .NETCory House@housecor |
  • 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.
  • Assumptions1. Web based2. RDBMS3. Enterprise line of business app
  • Astronaut AssessmentWe must use <shiny new technology> for this!Reinvent the wheel100% test coverageNever ORMAlways code to an interfaceUse all the patternsResume Driven Development
  • Consider Simplicity1. 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 CoupledNo TestsNo LayersNo APICoded to Interfaces100% Test coverageRich Domain ModelService 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.QualityDate CostFeatures*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 deadlinesanity.Quality software requires realistic deadlines.
  • Q: Is debt bad?LaterNowA: Is the deadline hard?
  • Hard vs Soft DeadlinesTrade showPublished advertisingX-team dependencies1st to market or deadNetwork effectsSingle loud customerWAGSalesman misspokeMS Project said so
  • Perfect architecture? Who cares.FacebookTwitterStackOverflowThe 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.
  • PresentationServiceDomainDataWeb Forms vs MVCJavaScript, CSS, jQuery, Knockout, Angular, IoCWeb API, WCF, ASMX, ServiceStack or POCOsC#, VB.NetEntity Framework, nHibernate, LLBLGen, Dapper, ADO.Net
  • UIAPIBusiness Logic(BLL)Data Access(DAL)PresentationServiceDomainPersistence
  • Layers vs TiersLogical Physical
  • TiersScalabilitySecurityAbstract complexityMinimize dependencesReusablePerformance costIncreased complexity
  • LayersSeparate concernsAid understandingAbstract complexitySupport testingMinimize dependencesStandardizeEnable reuseLeakMore code
  • Small app?methods = layers.
  • ORM honors DRY1. Database2. Class property3. Select statements4. Insert statements5. Update statements6. Delete statements7. SQL marshalling code1. Database2. 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 OOTBPass:• Lose control over SQL• DBAs lose control• Security concerns• Performance penalty
  • SOAHeterogeneous systemsAutonomousReusableFormalPerformance hitRisky changesBoth sides must test
  • Architectural LevelsL1SimplestthingL2Somewherein betweenL3Every toolin the shed
  • Level 1PresentationDomain &PersistenceWeb FormsActive Record PatternLinq-2-SQL, Subsonic, Castle ActiveRecord
  • Active RecordPresentationDomainData
  • Active RecordCustomer Address PurchaseCustomer Address PurchaseDB TablesClassesOne instance = One row
  • Active RecordSimple & obviousSpeedy dev and changesCompliments CRUD appsGood for simple domainNo OR mismatchHonors YAGNIRigid: Domain model = DBLeads to God objectLow cohesion: Breaks SRPHard to testTricky transactionsRepository pattern = pain
  • Level 3PresentationServiceDomainPersistenceASP.Net MVC, Knockout/AngularRepository PatternnHibernate, EF POCOs, DapperDDD with POCOsWCF, ServiceStack
  • Domain ModelIt’s all about the objects.
  • Domain ModelCustomer Address PurchaseCustomerwith list of addressesPurchaseDB TablesClassesNote OR Mismatch
  • Business Layer Patterns: Domain ModelComplex business domainLeverage design patternsSpeak business languageAbstracts ugly DB schemaLarge teamReusableLearning curveTime-consuming designLong-term commitmentDB mapping overhead
  • Level 3 SummaryTestableManage object lifecycleAOP via dynamic proxiesSwappable UI or DALSpeaks in business languageLeverage design patternsSlower initial devLarger initial dev costLearning curveMore places to changeSenior developers
  • Bottom Line: L1 vs L3
  • Points to Add a FeatureLevel 11. UI2. DB3. Implement BL (in AR class)4. Regen DALLevel 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 ComplexityLevel 3Level 2Level 1Effort toenhanceApplication Complexity
  • Architectural LevelsLevel 1 Level 2 Level 3Centralized 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 SelectionMVPJunior teamSmall teamSimple DomainTight timelineThrowawayNo security concernsLittle chance for reuseFlagship productSenior TeamLarge TeamComplex domainFlexible timelineLong-termSecurity mattersOther apps could reuse
  • Reading
  • Bottom Line1. Consider the simplest thing that could possiblywork.2. Context matters. X isn’t good or bad.3. Best practices have a benefit and cost.