Pragmatic Architecture in .NET


Published on

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.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Pragmatic Architecture in .NETCory House@housecor |
    2. 2. The problem.
    3. 3. X is good It Depends
    4. 4. Three Simple Goals:1. Cost vs benefit2. Contrast extremes3. Review our options in .NET
    5. 5. Why?Save money.Save effort.Save time.
    6. 6. Why Not?To improve my resume’.To challenge myself.To experiment.
    7. 7. Assumptions1. Web based2. RDBMS3. Enterprise line of business app
    8. 8. Astronaut AssessmentWe must use <shiny new technology> for this!Reinvent the wheel100% test coverageNever ORMAlways code to an interfaceUse all the patternsResume Driven Development
    9. 9. Consider Simplicity1. Do simplest thing that could possibly work2. Lean / Agile principles3. YAGNI4. 80/20 Rule
    10. 10. Consider Complexity• Unit Testing• Coding to an interface• SOA• Rich Domain Model• Layered N-teir architecture
    11. 11. Which is better?Tightly CoupledNo TestsNo LayersNo APICoded to Interfaces100% Test coverageRich Domain ModelService Oriented
    12. 12. It depends.
    13. 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. 14. Work expands to fill available time.Parkinson’s Law
    15. 15. Agile Estimation: Flex one.QualityDate CostFeatures*ArchitectureReusePerformanceSecurityTestingScalabilityDocumentation* Fat chance
    16. 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 deadlinesanity.Quality software requires realistic deadlines.
    17. 17. Q: Is debt bad?LaterNowA: Is the deadline hard?
    18. 18. Hard vs Soft DeadlinesTrade showPublished advertisingX-team dependencies1st to market or deadNetwork effectsSingle loud customerWAGSalesman misspokeMS Project said so
    19. 19. Perfect architecture? Who cares.FacebookTwitterStackOverflowThe problem is getting people to care.
    20. 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. 21. Enough Theory…Let’s get geeky.
    22. 22. PresentationServiceDomainDataWeb Forms vs MVCJavaScript, CSS, jQuery, Knockout, Angular, IoCWeb API, WCF, ASMX, ServiceStack or POCOsC#, VB.NetEntity Framework, nHibernate, LLBLGen, Dapper, ADO.Net
    23. 23. UIAPIBusiness Logic(BLL)Data Access(DAL)PresentationServiceDomainPersistence
    24. 24. Layers vs TiersLogical Physical
    25. 25. TiersScalabilitySecurityAbstract complexityMinimize dependencesReusablePerformance costIncreased complexity
    26. 26. LayersSeparate concernsAid understandingAbstract complexitySupport testingMinimize dependencesStandardizeEnable reuseLeakMore code
    27. 27. Small app?methods = layers.
    28. 28. ORM honors DRY1. Database2. Class property3. Select statements4. Insert statements5. Update statements6. Delete statements7. SQL marshalling code1. Database2. Class property3. .hbm.xml file
    29. 29. 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
    30. 30. SOAHeterogeneous systemsAutonomousReusableFormalPerformance hitRisky changesBoth sides must test
    31. 31. Architectural LevelsL1SimplestthingL2Somewherein betweenL3Every toolin the shed
    32. 32. Level 1PresentationDomain &PersistenceWeb FormsActive Record PatternLinq-2-SQL, Subsonic, Castle ActiveRecord
    33. 33. Active RecordPresentationDomainData
    34. 34. Active RecordCustomer Address PurchaseCustomer Address PurchaseDB TablesClassesOne instance = One row
    35. 35. 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
    36. 36. Level 3PresentationServiceDomainPersistenceASP.Net MVC, Knockout/AngularRepository PatternnHibernate, EF POCOs, DapperDDD with POCOsWCF, ServiceStack
    37. 37. Domain ModelIt’s all about the objects.
    38. 38. Domain ModelCustomer Address PurchaseCustomerwith list of addressesPurchaseDB TablesClassesNote OR Mismatch
    39. 39. Business Layer Patterns: Domain ModelComplex business domainLeverage design patternsSpeak business languageAbstracts ugly DB schemaLarge teamReusableLearning curveTime-consuming designLong-term commitmentDB mapping overhead
    40. 40. 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
    41. 41. Bottom Line: L1 vs L3
    42. 42. 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
    43. 43. Choice by ComplexityLevel 3Level 2Level 1Effort toenhanceApplication Complexity
    44. 44. 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
    45. 45. Architecture SelectionMVPJunior teamSmall teamSimple DomainTight timelineThrowawayNo security concernsLittle chance for reuseFlagship productSenior TeamLarge TeamComplex domainFlexible timelineLong-termSecurity mattersOther apps could reuse
    46. 46. Reading
    47. 47. 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.