Considerations for Content-Driven Applications

  • Article

A content-driven application's primary purpose is to deliver information such as documents, videos, and images. This is in contrast to other types of applications such as transactional applications for banks. In a content-driven application, one group of people either authors or provides some information for another group of people. An example of a simple content-driven application is one where employees upload expense reports and managers approve them. Content-driven applications also often provide collaborations spaces where users can work together and share the information.

SharePoint is an ideal platform for developing enterprise-scale, content-driven applications. The rest of this topic discusses how to structure content-driven information and who develops content-driven information. There are links to other pertinent guidance at the end of the topic.

Information Architecture and Site Topology

One of the most important aspects of a content driven-application is how the information is structured. Generally, a logical information architecture enables users to easily find the content they need. It also helps make the application scalable and maintainable. In terms of SharePoint, the information structure has many implications. It affects how your content is authored, secured, and aggregated.

Content can be stored at one of four levels. These levels are the farm, the Web application, the site collection, and the site. Each level has its own advantages and constraints. The Partner Portal application provides an example of the decisions you must make when you organize your information.

Contoso offers special promotions to all of its partners, but one partner does not necessarily receive the same promotions as another partner. The Partner Portal application provides the promotions to the partners. Several options for how to store the promotions were considered when the application was designed.

One approach was to author and store promotions in each partner's site collection. This makes the content easy to secure but difficult to maintain because there can be duplicate promotional information on each site.

A second approach was to create a central publishing site collection to manage all promotions and to use item-level access control lists (ACL) to secure the promotions. This makes the content easy to maintain but difficult to secure because all the individual ACLs must be maintained. Using individual ACLs can also have performance implications.

A third option was to place the partners into groups with different privileges. The appropriate promotions would be stored in a site collection that was dedicated to a group. This approach is a compromise between the other two approaches. It is harder to secure than the first option but easier than the second option. It is easier to maintain than the first option but harder to maintain than the second option.

The following diagram demonstrates the Partner Portal application's information architecture. It uses the second approach.

Partner Portal application's information architecture

Ff650273.b3c1fb4d-4c8b-4fa5-a353-7da1087e1671(en-us,PandP.10).png

Partners are authenticated in the extranet with forms-based authentication ("FBA" in the preceding figure). Each partner has a separate site collection. These partner-specific site collections include collaboration spaces to address incidents and order exceptions.

The Partner Portal also includes a site collection for the product catalog and for pricing information. All partners can view the shared content in the Catalog/Pricing site collection, but the Web Part content is personalized for each partner. The product catalog is shared content. All partners see the same catalog. Pricing information is specific to the partner.

All partners can also view the shared content in the publishing site collection for promotions, but the promotion page instances have ACLs. The ACL guarantees that only authorized partners can see that promotion page. Promotion pages are authored in the intranet and deployed to the Promotions site collection in the extranet. SharePoint provides publishing features that allow you to create content within your corporate network and deploy it to the extranet.

The following diagram shows the site topology of the Partner Portal.

Topology of the Partner Portal

Ff650273.95334667-7812-45d9-9f24-c2d885331136(en-us,PandP.10).png

Creating a Content-Driven Application

Typically, custom SharePoint applications are created by developers. For example, a developer can write a custom Web Part that retrieves data from a persistent store. In content-driven applications, a great deal of work is also done by non-technical content authors such as business analysts and Web designers. While developers use Visual Studio, content authors use tools such as Microsoft Office SharePoint Designer and the SharePoint Web user interface (UI). Traditional developers develop components such as custom controls and Web Parts. Content authors are responsible for activities such as setting up workflows, constructing page layouts, and authoring content for a page.

In other words, creating a content-driven application can involve many people with skills in many different areas. Each area has its own challenges. This guidance includes the following topics:

Home page on MSDN | Community site