Wednesday, March 4, 2009

Design Patterns vs. Architectural Patterns

After discussing MVC and it's use (or non-use, actually) in some of our apps it became apparent that a bigger problem existed in the design of these applications. Now most of our apps are used in house and were developed initially by a group of bygone developers and as part of the ongoing task of trying to enhance and adapt them we are reminded of the benefits of a strong attention and adherence to good design.

Despite being written in an Object Oriented language, much of the functionality in these applications is accessed through static methods and the model classes are nothing more than containers. When model objects tend to be simple containers we get this confusion about what the controller actually is. If all appropriate code were actually in the model classes the division would be a little clearer. LINQ makes things a little easier because it creates a bunch of your model for you and you can build on it using partial classes and such. The problem persists in LINQ apps though where if developers don't follw good OO design we can have all these static methods adding another layer of complexity to everything.

There is an article on implementing MVC in ASP.Net that outlines it pretty well. The part I don't like is that the model is not object oriented but uses static methods. It is still a good reference though. So in the context of ASP.NET, the way I see it is that the code behind is the controller and basically everything else that is not an aspx page is the model.

Both Design Patterns and Architectural Patterns will improve the quality of code when applied. It follows that using them together will yield even better results.

No comments:

Post a Comment