by First let me say, if you're looking for some tutorials or samples related to Sharepoint, this post isn't for you 😉 but feel free to read on.
At my new employer's, I have to do a fair amount of Sharepoint development. Well that phrase right there is just ridiculously large in scope. Allow me to elaborate.
I like to say, Sharepoint is to Web Sites as Microsoft Access is to Databases. Great great tools when used for their intended purposes. Very bad when attempting to stretch them to do things they just weren't intended to do. Yeah, you can make a front end to your database with Access, but if you need scalable deployable solutions for an enterprise or mass user base… Well, that just isn't how it's done. When Sharepoint is used as a collaboration site, it is awesome. Easy to set up and perform basic customizations. It can be styled very nicely by graphic artists and web design folks but when you try to stretch it with configuration settings alone, you end up with hard to maintain ugly solutions.
There are two flavors of Sharepoint. One is Windows Sharepoint Services (WSS) and the other is the Microsoft Office Sharepoint Services (MOSS). WSS is a free "Sharepoint Server" (the SS in WSS and MOSS) [ download: http://www.microsoft.com/downloads/details.aspx?FamilyId=D51730B5-48FC-4CA2-B454-8DC2CAF93951&displaylang=en (requires Windows Server 2003 (you can grab a Sharepoint Virtual Machine for the Microsoft Virtual Server as well), search the download site for Sharepoint VHD] MOSS is built on top of WSS and contains many additional webparts (I'll explain a little later) as well as the additional services and administration applications to create and manage web farms and multiple site collections. The webparts are the value-add. One such webpart is the Business Data Catalog which auto-magically allow various data sources (web services, databases, etc) to be used as a Sharepoint list while Sharepoint and the BDC do the heavy lifting of getting, caching, updating. etc.
Sharepoint has a few intrinsic "types" that one can work with on a SP site: Lists, Libraries, and Webparts.
A list is simply that, a list of "things". You can best think of these lists as database tables, though they are not stored as such. Each one comes stock with a few default columns such as created by, created date, last modified, that sort of thing. You then can add as many additional columns as you require to more properly define the "thing" in the list. Such as a list of customers, or regions, or support staff members, etc. These are all stored in a content database behind the scenes. If you modify this content database outside of using the Sharepoint provided tools and applications, you will void your support contract on that installation (which considering the MOSS retail server for enterprises in the tens of thousands of dollars in licensing, not something you want to void your warranty with!) These lists automatically have generated Create, Edit, and View pages which can be customized to further enhance working with them. And Sharepoint manages all this for you.
A Library is one of the default "applications" it provides. At it's heart it is a list, but it has special coding to in the support pages for the list that allow it work with special types of lists. Sharepoint comes with a few built in libraries, such as a Document Library and a Picture Library. As I mentioned these lists are persisted in a database and since images and documents (such as word files, or pdfs) are binary files, you need to store them, retrieve them, and view them in special manners, depending on what type it is. The libraries isolate that and do it for you and provide you with thumbnails in the picture library views and open up word to edit word documents, and excel to edit spreadsheets. All very integrated with office (hence the MO in MOSS, though WSS has these libraries as well.)
A Webpart is essentially a WebControl (in asp.net terms). They are custom web controls that implement various Sharepoint API interfaces. Calendar Control? That's a webpart.Ghant Chart? That's a webpart. Anything you can code as a web control can be a webpart. Sharepoint comes with a lot of different ones and they are all pretty useful for their purpose.
The sticky wicket is that you can do a helluva lot without needing to write a webpart. If you're doing Sharepoint development and not coding webparts, you are using MS Sharepoint Designer, a must have and of course, it is not free. But it does have a fine configurator for the DataView webpart. In a nutshell, the dataview interacts with some external source of data (web service, database, xml file on the files-ystem) and renders it to a list with a customizable XSLT. With something like that you can completely render the data with html markup to the page any damn way you want. You can even pass querystring parameters into it, pretty flexible and you can accomplish a lot of simple-ish apps this way)
I strongly suggest that anytime you discard all the other Sharepoint webparts and libraries to use dataviews and custom xslt, you INSTEAD develop your own custom webpart!! It will be far more maintainable in the end. And if it's a really complex application that needs to interact with a lot of systems around the enterprise, make a standard asp.net application and host it in a iframe webpart. That is what Microsoft intended. However, most IT managers just want everything in Sharepoint and they want it in there now because Jim in accounting made his group's Sharepoint site by himself in 2 days. Of course it's just a few custom lists and no theming or workflows. And that's great! But they don't understand the nuances in the differences of the applications they want, it just gets lumped under Sharepoint and that is a MISTAKE!
More later, cross your fingers boys and girls, the rabbit hole goes pretty deep on this one I suspect!
–Regards!