John Bair, a Network Engineer for a rural telecommunications company, has a problem. One of the joys of working for that kind of company is that you get to do all the work yourself and you have other responsibilities besides. But then, John gets to live in a truly beautiful place with lots of space, fresh air, and quiet. (Trust me, I've been to his little town. It's wonderful!)
But as the chief cook and bottle washer for computer systems, John has been struggling to upgrade to the latest versions of .NET. He wrote to me for advice. He started by telling me, "I'm a sole developer at my company, working on some pretty intense (for me) intranet web applications. I've worked with PHP and ASP in my websites for about 6-7 years but for the last 2 years, I've been learning ASP.NET in Visual Basic. ... I've got a list of questions ..." John said he was writing his message at 1 AM on Sunday of the Labor Day weekend and he was frustrated.
Leave a comment to the blog and give John the benefit of your advice!
John started out with this question:
--------------------
For two years, I have been working on a .NET application to replace an earlier one I wrote in classic ASP. Because of that I haven't taken the time to really learn the whole 3-layer, business logic layer and data access layer concepts. I have all my business logic and data access in the presentation layer. Everything has grown so large and complicated that I am stuck. I can't fix a major design problem without the fear of breaking everything, and I'm not that good at using the debugging tools either, due to constantly battling development environment problems in my IDE, computer, or config, etc.
I'm well acquainted with OOP concepts, I just don't have a lot of experience implementing them, at least not beyond the Web Forms controls. I just recently learned that .NET had an alternative programming model called MVC that I could use in place of Web Forms, but I've only read overviews about it. My platform is Windows Server 2003, SQL Server 2000, .NET 2.0, Visual Studio 2005. I ran into some problems getting things to work in VS2008 early on, so I gave up on it.
My top question is: When working on a large, complicated (due to business rule complexity and many inter-related tables), is the 3 layer approach really going to solve my problem of having too much complexity in managing/troubleshooting business logic errors by consolidating them into business logic layer classes and data access layer classes? Am I going down the wrong road altogether and I need to be looking at some entirely different approach?
--------------------
Here's what I told John:
--------------------
You do indeed have problems. This reminds me of my days as a software development project manager. You just don't know where to start picking at a tangled pile of yarn. I think that your problems might be parsed into two types:
1 - Architectural problems - Business logic layer and data access layer concerns.
2 - Technology problems - Using the current versions of databases, developer tools, etc.
I'm going to deal with those separately.
1 - Architectural problems
Everything you wrote about this suggests to me that you have the right ideas in mind. But many of those ideas were developed for large complex organizations as well as large complex problems. In other words, some of the main reasons you have separation between architectural layers is a recognition that the functions of the system will be:
- Performed in different physical locations (data entry is done in Hong Kong while transaction posting is done in London)
- Done by different people (you don't want marketing to have access to auditing's processes)
- Subject to different processing environments (outside sales reps use handheld devices; marketing analysts use Sun workstations)
How many of these things apply to you? Why are you complicating your life to accommodate them then?
Certainly, a thoroughly implemented layered architecture "can" simplify the modules in each layer because in theory, each module has fewer functions to deal with and a guaranteed interface with other layers. But in real life, it seldom works out that way. It usually turns into the sort of thing you're dealing with.
Rather than complicating the issue with architectural sophistication, I recommend a functional analysis of the original problem you're trying to solve. If you can divide that into sections with the fewest interfaces (For example - marketing only needs two types of information from production: product specifications and product availability.) then you can look at your current system and, hopefully, find some way to partition your system along the same lines. Then, if you can do that (a big "if" by the way), you can define a more limited project for yourself - something you can actually accomplish - to update, debug (and most importantly in your case) simplify that one part of your system.
One important rule here is: "Success in completing whatever you decide to work on is the most important selection criterion." Another rule is: "It's usually easier to add layered architecture to an integrated but structured system than it is to add structure to a layered but unstructured system."
If you want to read the master on this ... read the works of Fred Brooks. See my review of his latest book, published just a few months ago, The Design of Design.
2 - Technology problems
The technology you need isn't too expensive. If you want to go the totally free route, get Visual Web Developer and Visual Basic Express 2010. You can develop with them and the resulting programs are totally compatible with everything else Microsoft sells so you don't have to worry about converting anything to install in production.
But for just a little more money, less than the cost of a computer, you can get a MSDN subscription and get access to most of Microsoft's technology, including the latest software like Visual Studio and SQL Server.
I have always followed a rule of staying up to date. Microsoft provides current training and support for current products. Their record of support for yesterday's stuff is ... well ... not that good. And besides, the new tools really are better and easier to use.
Creating separate layers doesn’t necessarily have to mean creating multiple projects. An ASP.NET MVC project contains all three layers, but separates them into folders within that project. You can do that with a WPF MVVM project too, or any other project as well.
I can certainly recommend ASP.NET MVC. I’ve not done much web development and one of the main reasons was because I never liked it. They created WebForms as a web version of WinForms so, as a WinForms developer, you’d think that I’d appreciate that but it really just never felt natural to me. MVC feels much more natural to me for web development and the fact that it actively promotes separation of concerns and testability, the increased maintainability is exactly what you’re looking for.
I have to give MVC top marks. There are no WebForms server controls but I really don’t miss them. MVC also incorporates and contributes to jQuery, so that is a gain to balance the loss.