When you're creating a site for .NET, besides learning how to create user and server controls, how to work with dates, databases and datagrids (among others), the same can be said for learning and developing the ways to architect your site.
Because .NET provides so many different ways to construct a site you should ask yourself some questions while in the site architecture phase:
- What functionality needs to be re-usable?
- How many developers are you working with?
- Where will they be located?
- Do your graphic designers have any programming experience?
- Is the site content oriented?
- Does your site have a back-end administration area to create and control dynamic sections of your site?
- Does your team have a coding style or architecture process already? Does that change with .NET?
- Will you or your team be supporting the application, or will someone else, or another team?
- What are the development tools?
All of these questions become important when deciding how to create your application as it directly influences how your site can be developed and architected. Take for example the process of how sections are created in your site. Do you have one calling page, or entry point, that loads other sections or controls, or do you have one page per section? Each has their own benefits and can depend upon the answer to some of the questions asked above.
For instance if you already have a process where you create separate pages for each section, you and your team may feel more comfortable moving over a .NET application using the same process. If you've created past ASP applications using one calling page and dynamically loading, or creating pages from XML files, or database configurations, you'll most likely be coding the same way with code-behind and user controls.
A case can be made for either. Some would argue that using separate pages for sections is easier to maintain an application as a developer can just go directly to a page/url to find the code and update the process and functionality of that page (still using code-behind). Others may argue that it's easier to maintain an application using one calling file (or entry point) and separate user controls as functionality can be reused easier and you're not dealing with as many pages (however some may argue that maintaining multiple controls is the same as maintaining multiple aspx pages, or XML configuration files).
At the same time questions like whether the site is more content oriented, or more dynamic in nature where the end-user works with entry forms and admin systems, can help decide the best way to architect the site also. For instance if the site is more content oriented with the user doing more browsing, how sections are loaded and created may not be as much of an issue than if the site allows users to create their own web site and affiliate sites. In the latter example it might prove more efficient to have one (or a few depending upon how large your site is) entry point, or calling page, as pages and sections would be created on the fly, and in that case, configuration and features may be stored in an XML file, or database (where values are read per section, to load the different "widgets" of what the user has chosen from or designed as the section).
The number of developers, who will ultimately support the application, and what the skills, and skill level is of those developers can also play into how the site is architected. Take a simple thing like documentation. If the site is run in house and is a new initiative where only one or two of the same programmers may be working on it throughout its lifetime, documentation down to the exact detail may not be as much of a priority right away. If the site is for a client outside of your organization, where developers in their organization will eventually support it, than very detailed documentation is a must, and you'll most likely be commenting your code-behind and controls with XML comments (which may eventually be run through a documentation program), where as in the first example you could do without them right away.
And while some may argue that you should be doing very detailed documentation right away with full XML comments in code; tell that to a programmer with multiple projects where time is of the essence and the priority on the application may not be as great as the deadline on their company's largest project (where the powers that be just want to see the application in use).
Depending upon how much functionality will be re-useable can also determine how the conventions for namespaces, classes, and properties will be developed for the overall application. A good naming scheme can go a long way in documenting and making it easier for multiple developers to work on an application as well as what types of controls are created for your application.
At the same time, while .NET probably does the best job of allowing you to separate design from functionality, can you truly have 100% separation (see more on this at the end of this paragraph)? For instance even with code-behind, you still have to add in attributes to the main graphic template in order to manage them. A designer can still go in and change the color of a table (or have to redo the layout), and then accidentally overwrite the ID of the tag, or they still may have to have some knowledge of new HTML and Web Server controls. How much cross training a designer has, can influence how your pages are coded and designed, or how much interaction a designer has with the final pages themselves. * A case could be made that you can get 100% separation by loading in graphic templates which are XHTML, adding ID attributes and creating new files (ultimately building your pages), or by having the developers put in the final code attributes into the graphic templates (but then the question arises of how much extra time this takes in the development process).
Some other mitigating issues are location of developers, and what tools you are using in the development process. If your development team is spread throughout the country (or multiple countries) where individuals may not all be using Visual Studio .NET, this can greatly effect how you decide to architect, develop, and control the application, versus if everyone on the team is in the same building using Visual Studio.NET.
While learning and using .NET encompasses the many different namespaces, classes, controls, and nuances of the framework and new languages like C# and VB.NET, because of all these new tools at your disposal, you’ll also have to carefully plan and develop how you want to use them within the architecture of your site. In Part 2, we’ll look at one of the many ways you can go about creating an architecture for your site.
