I know all SharePoint gigs knows what I am stating in this article. To be honest this is more for may quick reference.

ASP.NET Applications vs. SharePoint Sites

Windows SharePoint Services development and traditional ASP.NET development differ in many ways. To help you understand the differences, we can compare ASP.NET applications with Windows SharePoint Services applications.

Figure 1 displays the different components and the interaction flow of a mainstream ASP.NET application.

Figure 1. Components and flow of a mainstream ASP.NET application

Users send requests to the server running Internet Information Services (IIS) for specific resources. These requests are accepted by IIS and delegated to an ISAPI extension DLL for further processing. Typically, resources are retrieved from the file system, such as .config files, .aspx pages, cascading style sheets, custom-built .NET assemblies, and user controls. All of these can act on the final response that is delivered to the user in his or her browser. In many applications, an interaction with a data store is also needed to store and retrieve data that is used to process the request and generate the response.

So, what is different when we compare Figure 1 with Figure 2, which represents the components and flow for a site based on Windows SharePoint Services?

Figure 2. Components and flow of a Windows SharePoint Services site

As you can see in Figure 2, Windows SharePoint Services abstracts developers from many of the details of hosting highly scalable, template-driven sites. In many cases, SharePoint administrators and experienced users do not even touch that low-level infrastructure. However, an understanding of it is helpful.

Windows SharePoint Services is a site-provisioning engine that relies heavily on schema definitions for templates of many types of artifacts that are important to its environment. There are definitions for site templates; for infrastructure pages such as the default.aspx, which make up the home page of a team site; for lists and libraries; and for helper pages that enable the interaction among the content that is stored in these different containers.

When starting a request for a Windows SharePoint Services page, there is interaction with the configuration database and the content database that retrieves the details of the request. This includes accessing the many XML files that contain the schema definitions, and accessing building blocks (Web Parts) that each have to execute their code that is encapsulated in a .NET assembly made available via either the global assembly cache or the local bin folder. The Windows SharePoint Services provisioning engine joins all these processes.

When we look at the traditional ASP.NET application again, what happens there if you need more than one application, maybe two, five, or even dozens? Figure 1 starts to look complex because there the same infrastructure is repeated for each additional application. Developers following the best practices and patterns can produce many re-usable building blocks, but much of the infrastructure must still be re-created each time.

By comparison, many Windows SharePoint Services sites—dozens, hundreds, even thousands of collaboration sites—can be delivered with one common provisioning engine. This is the power of using Windows SharePoint Services compared to using ASP.NET applications.

What You Develop for Windows SharePoint Services

Windows SharePoint Services is a solutions platform, which means that it is extensible and ready to run custom solutions. The following sections discuss the solution types that Windows SharePoint Services developers can build.

Assembly-Based Solutions

We can refer to these solutions as code-based solutions. Assembly-based solutions are developed with managed code (a .NET Framework language such as Microsoft Visual C# or Microsoft Visual Basic 2005) and compiled as a .NET assembly (a DLL). You can build different types of these solutions as well. The following table describes only some of the possible assembly-based solutions.

Table 1. Types of assembly-based solutions

Solution Type	Description
Web Parts	Building blocks for a SharePoint Web Part Page that deliver specific functionality to the visitor of the site. Web Parts can deliver data from stores that are not based on Windows SharePoint Services (such as Microsoft SQL Server and Oracle stores); capture data to drive business processes; aggregate or roll up information that is available in the SharePoint sites, or perform many other functions. Many Web Parts are available by default with both Windows SharePoint Services 3.0 and MOSS 2007.
Event handlers	A .NET assembly containing one or more classes that encapsulate code that is executed when certain events (such as adding an item to a list, creating a column for a document library, deleting a site, and so on) occur in SharePoint sites.
Information management policies	A rich policy framework in MOSS that developers can use to build custom policies that enforce certain behavior for content stored and managed in SharePoint sites.
Workflow Activities and templates	A workflow is a collection of activities Windows SharePoint Services or the information workers involved in the workflow must take. Numerous activities are available; however, you can create custom activities compiled in a .NET assembly and deploy them so that experienced users creating workflows in Microsoft Office SharePoint Designer 2007 can use them. Developers can also create workflow templates by using the workflow extensions for Visual Studio 2005 and deploy these as .NET assemblies to the SharePoint servers.
Timer Jobs	Assemblies containing code that can be scheduled and executed by the SharePoint Timer Service. An example is a job scheduled to create a report every evening for the administrator about documents that have been checked out for more than a week.

ASP.NET Resources

Figure 2 showed the infrastructure that Windows SharePoint Services uses to deliver the sites. This infrastructure contains many ASP.NET resources that are directly available and help deliver the simplified development experience you have with Windows SharePoint Services. As a developer, you can create and integrate your own resources. Table 2 describes the possible types of resources you can create.

Table 2. Types of ASP.NET resources

Resource	Description
Site page	An ASP.NET page that is stored in a document library in the site collection itself (and is thus stored in the content database). Can be used to deliver custom functionality (such as reporting or dashboard pages) to the user. Site pages can be dynamically created and offer much flexibility. However, because they are stored in the content database, Windows SharePoint Services applies a strict security policy to these pages, and no inline code is allowed. Additionally, these pages are run in no-compile mode.
Application page	A physical ASP.NET page stored in the `\12\Template\Layouts` folder. This folder is commonly shared by all Windows SharePoint Services sites that are hosted on the Web server. Application pages are ideal for creating additional administration features for SharePoint sites. Because they are not part of the database, inline code is allowed.
Style sheets and master pages	Together, these define the look and feel of a site, as well as the common functionality that is used by all the pages of a site.
Navigation control	ASP.NET-based navigation controls that deliver an experience based on the ASP.NET provider model. Windows SharePoint Services provides many default ASP.NET-based navigation controls. Custom navigation controls are typically required when delivering public (Internet) facing sites with Windows SharePoint Services.
User control	ASP.NET user control (.ascx file) that can deliver common functionality to the pages in SharePoint sites. Windows SharePoint Services provides several controls in the `\12\Template\ControlTemplates` folder. Create additional custom user controls, and for example, visualize them within the master pages. User controls can deliver a particular editing experience to the user, such as custom information management policies or custom fields.

Schemas

Schemas are XML-based solutions that use the Collaborative Application Markup Language (CAML). Table 3 describes the features whose delivery you can drive by using schemas.

Table 3. Types of features delivered with schemas

Feature	Description
Site definition	A custom template for sites that are deployed in the `\12\Template\SiteTemplate` folder. The core file for a custom site definition is Onet.xml, which contains the global definitions for the site along with the possible configurations.
Features	Introduced in Windows SharePoint Services 3.0, a modular approach for delivering custom schemas and functionality to SharePoint sites. Features can activate what you build and deploy. Many of the previously mentioned types of solutions are made available by using Feature definitions. You can find the list of deployed Feature definitions in the `\12\Template\Features` folder
Custom Lists	The schemas for custom lists and document libraries are also defined via CAML-based files, many times as part of a Feature definition. However, they can also be part of a custom site definition.
Site Columns and Content Types	Schema for re-usable packaged definitions of content that can be stored and managed in SharePoint containers (lists and document libraries). Site columns and content types are delivered through Feature definitions most of the time.
Custom Field Definitions	These CAML-based files, together with a .NET assembly that contains the code-behind, deliver additional field types that users can select from when creating custom metadata in a document library, for example.

Data Manipulation

All of the content that is stored and managed in SharePoint sites, together with all the configuration data, is kept in SQL Server databases that you do not need to interact with directly. Windows SharePoint Services and MOSS have very rich object models that are delivered by a number of .NET assemblies, of which the Microsoft.SharePoint.dll and the Microsoft.Office.Server.dll are the most important.

The server object model is accessible only when the application is deployed to one of the computers that is part of the server farm. If the application accessing Windows SharePoint Services is remotely deployed, use the Web Services APIs instead.

Solutions that directly interact with the SharePoint classes must have access to the SharePoint context of the sites (either the collaboration sites or the administration sites, depending on the type of the solution). Examples are Windows–based applications that are deployed to a server running Windows SharePoint Services, Web Parts that run in the context of Windows SharePoint Services, custom Web services that expose data in a customized way, Windows services that run on the SharePoint server, and more.

Numerous Web services are available in Windows SharePoint Services that expose most of the necessary data manipulation operations. However, when in need of custom functionality, you can always create custom Web services and have Windows SharePoint Services host and integrate them with the built-in Web services.

Thanks for reading. Please refer to the links below for more information.

HaPpY CoDiNg….

Partha (Aurum)