My Thoughts On Application Architecture
As you already know there are a lot of choices to be made when you are tasked with building an application. For anything that is not a one-off application or a prototype you need to give some serious thought as to how you will go about creating, or "architecting," your application.
If you are building a web application, you might start out by working with key stakeholders to develop user stories and mock-ups of the screens and the functionality they represent. Also during this initial phase you need to be asking your stakeholders questions like how many users will this application have? Is this a mission critical or otherwise important application? What is the projected lifespan of this application? Is the performance (speed) of the application important?
After you have asked some of these questions and understand the scope of your application
you are ready to start thinking about
how to put it together or, more fancifully
put, architect your application. If your
application needs to be fast, scalable, and easily maintained for future modifications you will want to spend a fair amount of time getting this step right, before writing a single line of code. The decisions you make here will be critical in determining the success of your application.
When I talk about architecting or putting together your application I am really talking about the design patterns you choose and whether or not you break up your application into several integrated projects that may reference each other. It is importnat to have a healthy separation of concerns. Having said that, however, I have seen this taken too far by having too many projects in a solution or the unnecassary use of design patterns. Like Goldielocks, you want the poridge to be just right!
Typically, developers have been breaking out their applications into three logical layers. These are the UI layer, the business logic layer, and the data access layer. That has given us some structure and separation of the various concerns of the application, but it has not been ideal. It has not been ideal because it does not enforce the rule that the UI layer talks to the busines layer and the business layer then
talks to the data access layer, etc.. You could always be in a code-behind page and call directly into the data access layer. Another reason that this model is no longer ideal is that it does not protect us from other forms of "smelly" code that can be dealt with by layering our code in other, more effective, ways.
Layers can be anything we want. Typically, in addition to a data access layer we will create a model layer for our data models, an abstraction layer, and a UI layer, which is often an MVC project in Visual Studio. Your business logic can be in this layer or you can put it in its own layer. Jefferey Palermo's discussion on what is called the Onion Architecture is great food for thought on this topic.
After you have made these architecture or layer and dependency decisions, it is time to think about what other design patterns might give your application the right amount of decoupling, while not unnecissarily making your code coplex.
Separating your code into seperate projects or layers within a solution is a start. Now it is time to think about patterns like the Repository, Unit-of-Work, and Factory pattern that will help you get the work of your application done.