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.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Is Your Architecture Crippling Your Unit Testing?Is Your Architecture Crippling Your Unit Testing? Last week I wrote a post that talked about Unit Testing and the need to make sure you are only testing one particular unit of code at a time.  The post was well received.  But […]
  • ASP.NET MVC – Model != BLL or DALASP.NET MVC – Model != BLL or DAL Last week I introduced the ASP.NET MVC framework by talking a bit about what the model, view and controller are.In the comments, John Meyer said, I respectfully disagree with your […]
  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • Cracking the Programmer’s Interview CodeCracking the Programmer’s Interview Code Several comments this week contribute to this week’s post.The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking […]
  • Watching Trends = Job SecurityWatching Trends = Job Security I’ve been programming for 21 years now.  Most of my career I’ve spent being on the bleeding edge.  This has helped when it came time to find work because I normally am one of […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

One Pingback/Trackback