ASP.NET Beginner's Guide To Creating UI, Business, and Data Layers in Applications
Part I


By Robbe D. Morris

Printer Friendly Version

Robbe Morris
Robbe & Melisa Morris
There are a ton of blog entries and .NET commentary on the importance of building your application with multiple layers of abstraction.  They tend to delve into the intricacies of Object Oriented design principles with a certain sense of moral purity in their tone and selection of terminology.  It is almost as if the goal of the discussion is for them to appear much smarter than the reader versus giving an absolute beginner in the .NET world a good head start with creating "reasonably well" designed applications.
Doing just that is what I'd to like provide via this article.  I've often found that the best way to help beginners is to provide the basic framework in their design for them and a few basic coding rules upfront.  They'll eventually catch onto the benefits with each new line of code they write.  So, this article will give you a rough set of rules to follow in Part II and a set of standard assemblies and what should be contained in them in Part III.
The most dangerous word that can be uttered during the design phase of your applications is the word assume.  Probably the biggest assumption you'll make is that "this is just a small application that won't grow into anything big".  The irony is that if you build your small application and it turns out to work quite well, it is almost a guarantee that you'll be asked to expand or integrate it with other applications.  So, what once seemed like a harmless variation from the basic guidelines for good application design has now come back to bite you in the ...


Here is a short list of basic assumptions you should make with every application
 
1.Every non-UI rule in your application will need to be utilized in other related applications and via other operating system environments.
2.Every UI rule in your application will be used in related applications via similar operating system environments.
3.You will be asked if your application can be used with another database type.
4.You will be asked if your application can be upgraded to support a multi-lingual environment.
5.You will be asked to expand the expected user base of your application both in size and feature utilization.
6.If you are the only developer on the project today, that will change tomorrow and you'll be responsible for bring them up to speed.
7.The core company business processes of today will change tomorrow and it is expected that your application can handle it with little or no effort.
 
The list above is not all encompassing but if you address all of them (even if only to lay some basic ground work in preparation), it is much more likely that you'll be able to regularly say "sure, we can do that" when asked to incorporate new features into your application to address a new business need.
Truth is, you can't always accurately predict how your application will evolve, only that it will.  You can assume that you will make some design mistakes in version 1.0 of your application.  You aren't that smart (neither am I).  You'll undoubtedly do something you wished you hadn't done.  However, you can take steps to reduce the impact and level of effort to correct these issues in the future while developing your application.
Next Page >                        
 
Part II:  Short list of 6 basic rules you can follow to help address these assumptions
Part III:  How do I set up the business layers as separate projects in my Visual Studio .NET solution?
 
 

Robbe has been a Microsoft MVP in C# since 2004.  He is also the co-founder of NullSkull.com which provides .NET articles, book reviews, software reviews, and software download and purchase advice.