An application is really like your house or at least part of your house… maybe the garage. It’s exciting when you get it first and you can see so much potential. You slowly start adding in a few bits here and a few bits there. Next thing you know, it’s filling up with. It’s all useful little things like the lawn mower, workbench, stepladder but together it all seems a lot like junk. There’s just no structure to it all. What you need is a plan to keep it clean and tidy. You might know where everything is but what if you’re away and one of your friends is searching for something? It could take days, if the even do find it! Software is no different… mostly.
Previously, I blogged about the importance of design patterns and a few short rules which will help keep you on the right track. Now I’d like to mention the importance of layers of separation. First, lets get a few things straight. There can often be confusion between the definition of layer or tier. The standard is that a layer is a logical separation where as a tier is physical separation. In the case of three-tier applications (or n-tier applications), the separation may be physical but it should definitely be logical. As we are more interested in coding rather than the physical installations, what we are really talking about here is a 3-layer architecture. It’s also worth noting that the “3” is just the standard design, n is more suitable. Your software may only have two layers or it might have even more the three layers.
Presentation Layer – This is the User Interface (UI). This layer should only be interested in what the user wants and displaying data it receives on the screen. It doesn’t need to care about where the data comes from, how it’s formatted or how anything is calculated.
Logic Layer – The Logic or Business Logic layer contains all the rules for your application. This should include things like how data is formatted, if a daily report has already been run for the day or if a client does not have sufficient funds to extract more money. The Logic layer does not need to know how to connect to the data or how many databases exist or if a database even exists at all. It should merely contain functions like RunReport or GetClientFunds. The Logic layer tells the Data Access Layer (DAL) what it wants and that’s all it needs to know. The DAL looks after everything else. The information returned from the functions can then be checked to make sure it does not break any rules such as insufficient funding.
Data Access Layer – Depending on who you talk to, the application requirements or the architecture used, this layer might be integrated with the Logic layer. Ideally, it shouldn’t be but we all know we don’t live in an ideal world. For large systems I would recommend that you segregate the layers as much as possible, having said that, there are times when it just isn’t needed and can be seen as over kill. Of course, all that is off-record! The last thing I want to do is get involve in a debate about the merits of rigid architecture models and purist views. So what is the DAL? This layer knows all about the Data Stores, what is being used (SQL database, XML files) and how to connect to it. It doesn’t know that users exist or that they want shiny looking ASP.NET presentations and it certainly doesn’t care. Separation of responsibility; This layer has it’s job to do and that’s all it cares about.
Data Store – This is where all the data is kept. It could be a simple XML file or a small SQL database or spread across multiple servers. Whatever it is, all it should know is that data is stored here. When a request comes in from the DAL then it checks the data and spits it back to the DAL. That data it gives to the DAL should be just that, data. It should not be information. The difference being that data is the raw format which could be very difficult for a user to decipher if they saw it where as information is data formatted into something which is clear and easy to read for the end user.
An n-Tier Architecture. (source: MS Patterns and Practises).
Now you may be looking at that and thinking ‘I really don’t need so much detail’ but please remember that you actually do! If you don’t have a strong architecture then your simple application will quickly become more complex when further changes are required and that’s not even thinking about the amount of time lost when someone else will try figure out your code or time you have to spend after not looking at it for several months!
When designing it’s important to know the in’s and out’s of each layer. How they connect to each other and which layer is responsible for what. That is the minimum knowledge you should have before starting the actual programming. Otherwise things will get messy! Very very messy.
I really can’t stress the importance of this enough. You might not have systems that require many changes after design or which are never scaled up or maintained but you WILL come across a situation where these layers are mingled to a point where they are impossible to separate. The presentation layer will contain SQL statements, the DAL will create webpage's or similar ridiculous situations. One experience of that and then you’ll understand the hard way. So start to remedy that now. Follow the structure and at least you’ll know that your code is of a high standard. If everyone done this then we’d be one step closed to a better world.
Subscribe