Executing a SharePoint application means using both the Common Language Runtime (CLR) and the ASP.NET engine. SharePoint itself comes with a bunch of services, along with tight integration with IIS using ASP.NET. In real-life applications, the complete scenario might appear more complicated. For example, in a farm with multiple servers, the execution environment will span several machines. While its logical structure still goes from farm to sites grouped into site collections, its physical appearance might be different. From a developer's perspective, the logical structure determines the objects you work with.

SharePoint provides a site collection as a container for sites. A site collection must have at least one site, the root site, which in turn can have child sites that run the applications. A site collection forms a multilevel hierarchy of instances that hold their own pages, lists, libraries, and individual users. SharePoint provides an inheritance mechanism that simplifies management of the sites. You can understand each site as a container of data, pages, and users working with that data. Each site can have its own administrator responsible for it and all its deriving sites.

The sites that function as logical containers for data store that data in lists and libraries. Libraries are lists that have the ability to store documents or files. Libraries are the basic instances that make SharePoint act as a document management system.

Lists function similarly to relational database tables, but are much more versatile. While a table is a strongly typed container for rows of data, a list can be used more flexibly. Lists are, however, not containers for storing any sort of object regardless of its structure. Using content types to describe a lists schema, you can define the structure of the objects stored in that list. A list can be bound to many content types and therefore store different kinds of structured objects, the so-called list items. In real-life projects, this results in an object schema that imitates the real-world counterparts of the objects. For instance, when you need to handle offers, invoices, and packing slips for customers, a list called Customer Documents could keep all three document types together in one place. The variations in metadata between the individual document types would be too unwieldy to store in a relational database table. A database developer would suggest using four tables—three for the different types and one that joins them together. A SharePoint developer, on the other hand, would use just one list, extended with three content types. The relation is implicitly defined by this with no additional effort.

Additionally, lists are available through a UI that's powerful for both developers and end users. As a list's schema supports a data model that's closer in nature to an object than a relational database, it's easy for nondevelopers to use lists to create sophisticated structured data stores. Even working with list data is quite easy, because the UI for viewing, sorting, filtering, and manipulating data is available out of the box. Relationships between lists can be quickly and simply defined with a lookup feature, which forms a many-to-many connection. Complex fields can hold predefined sets of data contained in drop-down controls in forms. And the access control mechanism is available at the list and item stages, with no code required.

Internally, list querying is based on CAML (Collaborative Application Markup Language). The generated LINQ to SharePoint layer internally translates queries into CAML. Using CAML, both developers and users can create powerful selections of complex data.

The data layer is not limited to internal lists. You can even connect to external data from SQL server databases, web services, XML, or similar sources. Internally, that data appears in a similar format to lists. The external data is bound using Business Connectivity Services (BCS). However, this service is not a component of SharePoint Foundation; it's available in SharePoint Server only.

Exposing data to the outer world is another subject that's well addressed in SharePoint. SharePoint 2010 supports WCF Data Services for common REST-based access to any data stored internally.

If you use SharePoint as an application development platform, it's likely that you'll work on some sort of application logic as part of a development project. Such logic is usually encapsulated in modules that form a business logic layer. Technically, the logic makes use of the various built-in features, such as ASPX pages, web services, workflows, event receivers, and timers. Along with the .NET Framework, a huge toolkit is available to form the logic.

In simple projects it might be acceptable to spread the logic through the instances SharePoint provides—Web Parts, application pages, workflows, and event receivers. Such projects generally have only one or two of these instances and remain easy to maintain. However, from the perspective of professional software development and application life cycle management, a different strategy is needed. It makes sense to create a unique business layer that handles all relevant logic in one or more assemblies. The instances where the logic gets triggered should have interfaces only. That means you have to take care of your project's structure and the ways the data flows between the instances.

SharePoint itself does not come with a part that is dedicated to the logic. Moreover, the internal logic is spread over several parts, and cannot be found in one place. You should be aware of this, and instead create a dedicated business logic layer for your SharePoint application.

The most sophisticated business logic is unusable if the user cannot exploit it easily. The UI layer is responsible for providing a modern and accessible way to interact with your application. SharePoint includes a browser-based engine and a web-based application. This has some nice implications, such as zero deployment and a broad range of clients, but it has some disadvantages compared with Windows applications as well (mostly concerning the limitations of HTML and browser environments). SharePoint defines basic UI elements and conventions for how to use these elements.

While you may be tempted to customize SharePoint's default design, we recommend against departing from it. Consider that the preferred way to extend SharePoint is through Web Parts. Web Parts can only appear in certain zones within a Web Part page, and users can arrange, close, or resize them. The available options don't change the UI—and neither should you while creating it. Treat regular application pages as part of an existing system.

Microsoft also recommends against creating new master pages, and instead recommends that you only change the basic layout and/or replace the company logo. This is something of a paradigm shift, since ASP.NET developers are used to having total freedom when designing their application's UI. But why should you accept these restrictions?

Primarily, many users have experience with the standard UI, and changing it could be potentially confusing for them. Likewise, you should anticipate new employees to arrive from other companies with SharePoint experience. If your intranet looks radically different from the standard, their prior experience won't be of use in your organization.

Any security layer consists of two basic actions: authentication and authorization. Authentication identifies users by some combination of name and password, a token, or a smart card with a PIN (personal identification number). SharePoint has a comprehensive security model, and there is no need to reinvent the wheel. SharePoint makes use of IIS for authentication purposes, which in turn uses common data stores such as Active Directory. The authorization module itself is based on ASP.NET membership providers that can be replaced, customized, or enhanced using common techniques.

Once the user is authenticated, the security layer is responsible for informing other modules what the user is authorized to do or what data he or she is allowed to access. SharePoint comes with three predefined groups to handle users in categories. These groups can be extended by assigning common roles for data access. The security settings inherit from one level to another, such as from a site collection to its child sites. However, you can break the inheritance and choose another security model on any level; none of this configuration requires writing code. The security model works down from the farm level to the individual list items. For coders, the security model is available through particular classes. Specific base classes for application pages are available for use with the built-in security model or for allowing anonymous access explicitly.

Whatever you need to implement, you can extend and customize the ASP.NET security model that SharePoint is built on.

The toolbox is filled with everything you need to customize, extend, and adopt almost any part of SharePoint Foundation. This includes dedicated and exclusive tools such as SharePoint Designer, as well as common tools such as Visual Studio 2010, which comes with a couple of preinstalled project and item templates. There are several tools, notably stsadm and the PowerShell cmdlets, which support scripted administration and deployment processes. Also included is the SDK (software development kit), which consists of manuals, guides, step-by-step-instructions, samples, and references.

Because of SharePoint's two-pronged appearance, it's not a pure developer environment. While some other platforms may put all the power into the developer's hands, SharePoint also caters to end users and administrators with its tools. Consequently, for certain tasks, developers will need to use SharePoint Designer, the web UI, or Central Administration, as there may be no developer-specific alternative. In this way, your toolbox is not limited to Visual Studio and its relatives—it encompasses everything that comes with the standard installation. We strongly recommend that you treat SharePoint not just as couple of classes and controls, but also as your favorite platform for accomplishing daily tasks. SharePoint is used by Microsoft as a platform for Team Foundation Server administration, as the interface used by Project Server, and as the heart of the Office platform. This indicates that you're already in two roles—developer and user.

Enterprise content management (ECM) is in the 21st century what file shares were in the past. The overwhelming quantity of documents and the various workflows that manage the ways people create, approve, edit, and update these documents create challenges for ECM systems. Content management systems consist of various built-in services, storage capabilities, and features to help developers focus on business logic and workflow creation, leaving infrastructure tasks to be completed by SharePoint.

Records management is another advanced subject in the field of ECM; it addresses the need for a reliable and auditable document store. Using ECM records management, it's possible to create custom solutions on top of the basic modules SharePoint Server provides.

Document and enterprise management systems have been used to organize content in various ways, including taxonomies, category trees, and tagged documents. Since Google's success, we know that full-text search is a very user-friendly organization strategy. With the increasing number of documents found on file shares in companies around the world, search capabilities have become standard.

SharePoint's search capabilities are on par with this standard, offering you highly customizable and extensible ways to create sophisticated full-text search functionality.

The ability to access timely, pertinent data from many sources has become a necessity for company leaders. Knowing what's really going on in an enterprise is essential for managing a company well. To address this, SharePoint provides Web Parts that display key performance indicators, chart controls that express complex data simply, and business connectivity services that gain access to LOB systems quickly. SharePoint now acts as business dashboard.

Particularly impressive in this regard is the Excel services feature—available as a browser application—which extends the Web Part–based view into a full-blown spreadsheet environment. Spreadsheets are stored in document libraries, making them available under central rights management to the targeted audience.

Forms management is part of almost every enterprise's intranet. From simple employee self-service to absence management, travel expense reimbursement, and internal orders for equipment, there are many applications that benefit from easy-to-create, flexible forms. Combined with workflows, forms management allows you to express internal processing through the SharePoint technology and automate daily tasks. Both forms and workflows in SharePoint are highly customizable, programmable, and well supported by additional tools.

Blogs and wikis are available in SharePoint Foundation already. For most applications, these are the entry points into community support within an enterprise. SharePoint server adds some features that address a broader audience. They make social computing available to teams as well as entire enterprises. One core community-based feature is MySites, which allows employees to introduce themselves and express their thoughts in a managed and centralized way.

Blogging allows users to express their ideas quickly in a relatively unstructured way. It complements the full-text search engine paradigm described previously. Adding and updating articles on a wiki is more structured, and complements the link paradigm that the whole Web is built on. Giving the ordinary user the power to create pages without knowing anything about HTML empowers common people to take part in creating content in a more powerful, less structured way. SharePoint's ability to allows users to create sites, blogs, and wikis has in part pushed it to its current level of popularity. While SharePoint Foundation offered these capabilities already, SharePoint Server's Publishing feature takes them even further. The larger an enterprise's sites and the greater its activity, the more it will benefit from content-publishing modules.