App Arch How Tos Posted to CodePlex

As part of our patterns & practices App Arch Guide 2.0 project, we'll be creating step-by-step How Tos.  The How Tos help turn some of the concepts into action.  They are particularly helpful for some areas where there's friction or complexity.  Here's our initial batch of draft How Tos on CodePlex:

They're still works in progress, but this way you can start to bang on them and give feedback.

My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • App Arch Guide 2.0 Overview Slides
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Components
  • Key Software Trends

    • Published 02 October 08 03:17 by J.D. Meier
    Filed under:

    Comments

    # Dew Drop - October 2, 2008 | Alvin Ashcraft's Morning Dew said on October 2, 2008 8:48 AM:

    PingBack from http://www.alvinashcraft.com/2008/10/02/dew-drop-october-2-2008/

    # John Rusk said on October 8, 2008 4:33 AM:

    JD,

    Regarding giving feedback, what is the best place on the CodePlex site to give feedback?  I left a couple of comments on individual pages, although I'm not sure whether comments show up in the "what's new" feeds - i.e. maybe nobody saw them.  Is it better to use the Discussions tab?

    # J.D. Meier said on October 8, 2008 11:58 AM:

    @John -

    Good question.  We'll have somebody on the team sweeping for comments each week (we've been heads down at the moment).  The discussion might be the best spot, although I'm going to check w/the CodePlex folks how I can see rollups for comments on pages at a glance.  

    I found your comments -- I'm going to have somebody on the team reply on CodePlex, but my fast answer is that, I think you're right.  In general, the Domain Model pattern does not map easily to existing relational database structures (brownfield scenarios.)  I think the other key issue is the flexibility/lifetime of the application.  For simple apps, you won't see the ROI.  For any significant app, you'll see the ROI of the Domain Model over time, as you need to flex and bend it.  Fowler has a nice chart of this.

    # John Rusk said on October 9, 2008 2:46 PM:

    Thanks JD.

    I wonder if the standard (e.g. Fowler) view on ROI is less applicable with the recent tooling.  IIRC his ROI comments were made a few years ago and were based on the fact that standard tooling (e.g. datasets) used to help developers a lot with the other patterns, but there was less (out-of-the-box) tool support for Domain Model.  

    These days, I feel it may do LINQ-to-SQL a disservice to say that the domain model pattern has poor ROI on small projects.  I'm using it right now and, although we are using it on a large project, I would have no hesitation in using it on small projects too.  Likewise, I would have no hesitation in adding my own business logic to the LINQ-generated entities (i.e. I would definitely use the generated entities as the basis for Domain Model rather than using them as behaviour-less "Domain Value Objects").

    # J.D. Meier said on October 9, 2008 2:56 PM:

    @John

    Good points and I agree there's a shift in tools (there's momentum in new, but inertia in old)  

    Context matters.  In your scenario, do you create/control/change the database schema?  How well do you see the concepts scale across a team?  How do you rank it in terms of complexity/simplicity from a developer skill level?

    # John Rusk said on October 10, 2008 3:27 AM:

    Good question about the database schema.  The interaction between schema changes and the LINQ-to-SQL designer was a point that concerned us at the start of the project. So much so that I wrote this (http://www.codeplex.com/Close2Poco ) as a possible alternative to using the designer.  But we decided to try using the designer first, and we're still using it.  There is some pain, but not nearly as much as we feared.

    In terms of complexity/simplicity, it's not bad at all.  I'm not sure it's necessarily any more difficult than the "old way" with datasets.  In fact, I was talking to a young self-taught programmer recently, and he was raving about how easy LINQ-to-SQL was.  (I never clarified whether he was doing Domain Model or "Domain Value Objects", but I could certainly understand how he felt that LINQ-to-SQL made his life easier and much more productive.)

    Anyway, your're welcome to email me privately if you'd like to discuss our project in more detail than I can share publicly.

    New Comments to this post are disabled

    Search

    Go

    This Blog

    Syndication

    Page view tracker