With the deployment of the gold release of ASP.NET MVC, the topic of patterns are hot and heavy again, and I am getting reader emails about “What pattern do I use for this or that”. I answer when I can, but it needs to be understood that The Gang Of Four were writing for a pretty broad kind of software development, and a lot of their thoughts only peripherally apply to the world of business programming.
Most of us write programs that accept data from some source – usually a user – and then deliver it to some source – usually a report. This is not what The GoF had in mind when they wrote Design Patterns. In fact, you’ll notice that even Model View Controller – the pattern behind the ASP.NET MVC – is Martin Fowler’s; it isn’t even in Design Patterns.
Speaking of Fowler, he is a great author to check out when making decisions about a pattern for the data-driven applications usually built by VB.NET programmers. I strongly recommend his Patterns of Enterprise Application Architecture. The Object-relational structural patterns, especially, define a lot of the thought that needs to go into object-oriented applications persisting to a relational database.
What patterns do I use? I believe in single abstraction of the domain. I think that you need significant separation between the database and the domain and application layer, but to wrap ever single little thing in interfaces is a waste of time for 80% of stovepipe applications. In general, using Fowler’s terminology, I use a lazy mapper model. The domain objects (like person or organization) call data objects that relate directly to tables in order to gather or persist information. If it is a really big application, I will go ahead and go to that next level of abstraction and implement that separated interface that I generally do not like.
A final note – design patterns are not ‘philosophical constructs of programming.’ They are real, important, significant and weighty contributors to software design. If you are not designing your software, you should be and it is tough if not impossible to design without an approach and the approach is defined by the pattern. Please don’t allow the hackers on a team to direct the flow away from a sensible approach.