Introduction to Webparts in Sharepoint

About WebParts

Microsoft first introduced Web Parts in Windows SharePoint Services (WSS) 2.0. Information workers and developers quickly adopted Web Parts because they enable end users to modify the content, appearance, and behavior of pages through a browser.
Not only could users easily modify the content and experience with the browser, but they could also modify pages for just their own experience, rather everyone ’ s shared experience. Web Parts became so popular that the ASP.NET team decided to add a Web Part Framework to ASP.NET 2.0. The ASP.NET 2.0 implementation is different from the WSS 2.0 implementation in that ASP.NET 2.0 adds a new component to the page: the WebPartManager . The WebPartManager control is responsible for managing all aspects of Web Parts on the page. It knows what Web Parts are allowed on the page, what Web Parts are already on the page and which Web Part zones they are in, any connections that have been established between two Web Parts, as well as the personalization data for each Web Part. Personalization data contains all the settings, or values, set on the public properties, for a Web Part. This is very different from the WSS 2.0 Web Part Framework in that each Web Part maintained its own connection and personalization information and Web Part zones managed which Web Parts were in each zone.

What happens when a Web Part is added to a Web Part zone?

SharePoint adds some XML to the Web Part zone that contains information about the assembly
containing the Web Part and the Web Part class itself. This XML also contains the values of the public
properties on the Web Part class.

<WebPart xmlns=”http://schemas.microsoft.com/WebPart/v2” xmlns:iwp=”http://schemas.microsoft.com/WebPart/v2/Image”>
<Assembly> Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c </Assembly>
<TypeName> Microsoft.SharePoint.WebPartPages.ImageWebPart </TypeName>
<FrameType> None </FrameType>
<Title> Watch My Gears Run </Title>
<iwp:ImageLink> /_layouts/images/GEARS_AN.GIF </iwp:ImageLink>
</WebPart>

This XML, shown in above, is then stored as personalization information for a specific user (if the personalization scope is set to User) or for all users who access the page (if the personalization scope is set to Shared) depending on the mode of the page. The next time a page is requested, SharePoint loads the personalization information for the Web Part, which tells it which class to load from which assembly and the values of the public properties to set on that class. The Web Part is then loaded within the ASP.NET 2.0 page life cycle, which generates the rendered HTML output.

WebParts Base Classes

Microsoft has provided two base classes from which developer can create custom web parts
ASP.NET 2.0 — System.Web.UI.WebControls.WebParts.WebPart
WSS / SharePoint 3.0 — Microsoft.SharePoint.WebPartPages.WebPart

Why to use ASP.Net web part class not SharePoint web part class?

When creating a new Web Part, Microsoft ’ s recommendation is to always create ASP.NET 2.0 Web Parts instead of SharePoint - specific Web Parts. Web Parts created from ASP.Net web part class (System.Web.UI.WebControls.WebParts.WebPart) are fully supported in Windows SharePoint Services, and can be used not only in ASP.NET applications but also in Windows SharePoint Services too. The SharePoint web part class was designed specifically for SharePoint sites, and Web Parts that inherit from this class can be used only in Windows SharePoint Services sites.
When creating new Web Parts, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or Microsoft.SharePoint.WebPartPages.WebPart. The Windows SharePoint Services WebPart class exists primarily for the purpose of backward compatibility (Web Parts written for Windows SharePoint Services 2.0 continue to work in Windows SharePoint Services 3.0 without modification).

References
Professional SharePoint 2007 Web Content Management Development
Webpart Class