Jaa

App Arch How Tos Posted to CodePlex

  • Artikkeli

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

Comments

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

  • Anonymous
    October 07, 2008
    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?

  • Anonymous
    October 08, 2008
    @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.

  • Anonymous
    October 09, 2008
    The comment has been removed

  • Anonymous
    October 09, 2008
    @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?

  • Anonymous
    October 09, 2008
    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.