App Arch How Tos Posted to CodePlex

Dew Drop - October 2, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - October 2, 2008 | Alvin Ashcraft's Morning Dew — Thu, 02 Oct 2008 15:48:41 GMT

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

re: App Arch How Tos Posted to CodePlex

John Rusk — Wed, 08 Oct 2008 11:33:15 GMT

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?

re: App Arch How Tos Posted to CodePlex

J.D. Meier — Wed, 08 Oct 2008 18:58:08 GMT

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

re: App Arch How Tos Posted to CodePlex

John Rusk — Thu, 09 Oct 2008 21:46:57 GMT

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").

re: App Arch How Tos Posted to CodePlex

J.D. Meier — Thu, 09 Oct 2008 21:56:06 GMT

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

re: App Arch How Tos Posted to CodePlex

John Rusk — Fri, 10 Oct 2008 10:27:32 GMT

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.