Principles of Programming Architecture


Yesterday I was talking with a friend of mine about a project we have been working on that was written by some other company.  We were speculating why the code was written as it is when we started discussing design theory.

The issue we have is that even though much of the code we are working on is compiled using ASP.NET 2.0 or greater, much of the code still looks like it was written in ASP.NET 1.x.

But isn’t Visual Studio supposed to let you upgrade from one version to another easily?

Yes, of course.  Unless you try to out-guess Microsoft and create your own architecture.  And that’s where the problems come in.  So here are some pointers for the future:

  • If you are going to develop your own framework, make sure your framework works with whatever Microsoft gives you.

This probably sounds obvious.  The danger in not doing this is that you’ll end up having to carry your architecture forward or rewrite your code to match what Microsoft has changed.  But how can you know if you will be doing something that won’t work in the future?  You can’t.  But there are a few ways you can mitigate the risk.

  • Never create an architecture based on version 1 of anything Microsoft releases.

Again, this should be obvious for anyone who has worked with Microsoft products for any length of time.  But for those of you who are new to programming and haven’t seen the pattern over the years you may be inclined to “fix” version one yourself.

That will get you into trouble.

Version one is always a placeholder product.  It isn’t anywhere near the end product.  Don’t try to fix it.  If you can’t live with it, don’t use it yet.

  • If you have to explain your architecture to another programmer, your architecture either needs significant work, or it will break on the next release from Microsoft.

I’ll illustrate.

When I was working for a training company, it was not uncommon, once people caught the concept of inheritance, for them to want to create a master page kind of thing using a parent class for the master page, and then just provide the main content in the child page.

The problem with this strategy is that if you are not familiar with the architecture, it is unlikely that the next programmer will know where to look for the master page content.

In fact, the main problem we have with the architecture that we inherited from this other company is that not only do they have this funky master page inheritance thing going on but tracking down how data is getting from the database to the presentation takes 15 minutes to half an hour to figure out each time I need to do it.

There is a balance that is needed between encapsulation or separation of concerns and simplicity.  Some systems I have worked on in the past put the SQL in the view and other systems encapsulate so much that not only are the implementation details hidden but how to implement the connection is hidden as well.

If the implementation is hidden, you’ve gone too far.

Related Post

One Response to “Principles of Programming Architecture”

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail