Web Part architecture is a nebulous domain of knowledge, depending on both administrative and developer skills. Knowledge of the Web Part architecture is useful to an administrator, who has to manage some custom Web Parts, and useful to the developer, who has to design custom Web Parts and package them for later deployment.
A Web Part can be as simple as a single configuration file, or a .webpart or .dwp file, or an installable package, which may include a number of assets. Understanding different elements of a Web Part is the key to best development practices and effective troubleshooting.
Although ASP.NET Web Parts work slightly differently, all SharePoint Web Parts must derive from one of two base classes, and they cannot utilize User Controls or Custom Controls directly as Web Parts:
Microsoft.SharePoint.WebPartPages.WebPart-based Web Parts may be
considered legacy, they do offer several features that are not possible to
achieve with ASP.NET Web Parts, including:
Cross Page Connections
Connections to Web Parts placed on pages outside of Web Part zones
Client Side Connections
Data Caching infrastructure
Architecturally, Web Parts are most similar to .NET Custom Controls, but offer several important benefits and work with the underlying SharePoint Web Part infrastructure.
In order to use SharePoint Web Parts, you must have a web page that contains a
WebPartManager object ...