Software Engineering, Project Management, and Effectiveness
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
PingBack from http://www.alvinashcraft.com/2008/10/02/dew-drop-october-2-2008/
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?
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.
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").
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?
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.