As a SharePoint and .NET Developer, I can attest that designing and developing SharePoint 2010 solutions is different from designing and building .NET solutions. In many ways, it's easier to build .NET business applications because Developers don't have to figure out how to build what a customer wants using an existing framework. On the other hand, basic business applications can be built rapidly with SharePoint 2010.
When a SharePoint Developer builds a SharePoint list SharePoint creates the add, edit and display forms, a mobile version of the list or library, an all items view (that lets you see all the data added to a list); and, RSS feed capability. Imagine the time it takes to manually code all of that functionality in a .NET application. Time-to-market and reduced costs is one key reason big businesses have deployed SharePoint. (The other reason, of course, is they gain the expertise needed to compete for multimillion dollar federal government contracts. But that topic is fit for a different article.)
The other benefit SharePoint brings to the table is the ability to easily implement security. With SharePoint sites, SharePoint Site Administrators add the roles and then add people to the role to grant access to a site. If the security isn't configured properly SharePoint automatically prohibits rather than permits. And, SharePoint supports fine-grained security. This means the Site Administrator can add roles and people directly to SharePoint lists instead of accepting the default list security, which is the list inherits the "site's" roles and users. When fine-grained security is used two people with different permissions can look at the same page and see different content. For example, if one person is in sales and another is in marketing; the sales list can be configured so only sales people see it. The marketing list can be configured so only marketing people see it. There may also be lists, on the same page, that allow both marketing and sales to see the list items. If you understand how SharePoint security works, it doesn't take very long to figure a site to behave the way a customer wants it to. Security flexibility and secure access is one key reason nearly every branch of the US military has also adopted SharePoint.
But the advantage many .NET Developers see with .NET is they don't have to figure out how to use an existing framework. They can build a web application without any barriers; and I whole heartedly agree with this.
But for SharePoint 2010 Developers who learn out-of-the-box SharePoint Server 2010 features, SharePoint Designer and Visual Studio--the world is theirs (figuratively speaking). Building robust, collaborative web applications can be completed within days or weeks (unless complex, custom functionality is requested). And, these sites can include spunky workflow functionality that further streamlines a business process through automation. SharePoint Developers can also use SharePoint Server, SharePoint Designer 2010 and Visual Studio 2010 to build custom lists and/or libraries. Or, they can create an .aspx page, using an existing master page, and add webpart zones (which are used to hold lists and libraries). The Developers or users can then drop the desired lists and libraries on the page, which is then ready to be deployed.
Using SharePoint to Design a Customer List or Library
The following paragraphs discuss the various ways a product ordering system could be designed using SharePoint. (Note that in the real world SharePoint would be used with Microsoft Commerce Server to build an integrated ordering system. However, I still think the ordering system is a feasible design to use as an example.)
For this example we are going to walk-though designing multiple Products Lists (a Product List for each product category) and a Shopping Cart List. We will have a User role and a Product Administrator role. In our design, the User role can view all products and edit two fields on the Products List. However, the User role cannot create new products. In addition, the User role can create and update items in the Shopping Cart list.
In our design the Products Lists will be built from content types. We are building the Products Lists from content types because we would only need to build the list once. That list is then available to the entire site. This will allow us to rapidly build the Products Lists. The Shopping Cart will be built from a custom list. We will design a reusable workflow and associate it with our Product content type. We will also add a workflow to our Shopping Cart.
Product Content Type
As previously mentioned the Product content type will be used to build multiple Product Lists. Using a content type means the SharePoint Developer only builds a Products List once.
- To begin, we create a list and give the list a name. For example, the first list is created and called Arts, Crafts & Sewing.
- Once the list is created we use the List Settings option to enable the ability to use content types. SharePoint automatically adds the list content type and sets it as the default content type.
- Next we add the Products List content type we created. The Arts, Crafts & Sewing list inherits all of the columns in the Products List Content type.
- Now we have to set the Products List Content Type as the default content type so we can delete the list content type SharePoint added.
- Lastly, we can add our Arts, Crafts & Sewing items to the Arts, Crafts & Sewing list.
We repeat these five steps for each product category. Using content types means we can very quickly create usable lists for all of the product categories. The left menubar displays the name of each list we created. The Administrator can click on a product category, on the left menubar, to add the products. The users can then click on a product category to view the list of items added by the Administrator. The following picture shows the the Baby category selected by a user.
Notice the Limited View is shown to users because the users can only see the columns needed to identify the items to be purchased. The Administrator uses a different view because the Administrator must add columns the user should not see. For example, the Administrator adds the number in stock column, and the quantity sold (a workflow is used to deduct the quantity sold from the number in stock to keep the number in stock current). The Administrator also adds the restock level column. The system can use this column (and a separate workflow) to automatically reorder a product when number in stock column reaches the number in the restock level column.
The system design calls for the following site columns to be added to the Product content type: Product Name, Category Name, Product Description, Product Price, Product Size, Product Price, Quantity in Stock, Quantity, Add to Cart (which is a checkbox where checked = yes and unchecked = no) and others, as applicable.
Note that there are many ways to build the same application in SharePoint. For example, instead of using content types we could design the application to use a Product Category list template. To do this a Product Category list is created with all of the relevant columns. The SharePoint Developer saves the Product Category list as a template. Then a list is created for each product category using the template.
Alternatively, the design could use a Category list made from a Category Content Type. The Category content type would have two columns as follows: Category Name and Category Description. The Product Content Type would then have a Category look-up column so the Product Administrator can select a category from the Category list when adding products. A third design option could be to add a Category column (using the Choice option) directly to the Product content type. Then add the categories to the Category column so the Product Administrator can select the desired category when adding new products.
However, in this design a separate list is to be created for each category. SharePoint will create the navigation so the Developer will only have to reorder the items on the left navigation bar so they display alphabetically. The initial number of items that will automatically display in the Product list is 100. The system design can also use a SharePoint List Filter webpart to filter products within a category. In addition, products can be sorted by price. The design could also allow for users to rate each item.
Whenever a SharePoint list is created a Title column is automatically added. This column automatically links to the View Details page, which enables a user to see all of the columns associated with the list. However, we can use SharePoint Designer to create a custom View Details page. We only add the columns the user should see to the new View Details page. When the user clicks an item under the Title column (which has been renamed to Product Name) the user will see the custom View Details page we created.
In this example we named our custom View Details page as follows: View Product Details. Whether the user clicks View Product Details option from the shortcut menu; or, clicks the item name under the Product Name column the user will be directed to the View Product Details page.
We also designed our View Product Details page so all fields of the fields are read-only except the "Quantity" field and the "Add to Cart" checkbox. The User role can update these two fields indicate the quantity of a product to be ordered and add the item to the shopping cart. When the Save is clicked on the Product View Details page, the form checks to see if the Shopping Cart checkbox is checked. If it is and the Quantity field is empty, a message displays telling the user the Quantity field is required. Or, if the user adds a value in the Quantity field; but does not check the Add to Cart checkbox then the "required field" message displays for the Add to Cart checkbox. This ensures the user does not complete one field and not the other.
The Shopping Cart
If no errors are found the updated occurs, which initiates the workflow. The workflow checks the Quantity field only (the form already performed the checks to make sure both the Add to Cart field and Quantity field are both completed). If a value is found the workflow captures the product name, quantity, calculates the price for the items, etc. and inserts a new list item to the Shopping Cart list. The User role never directly adds items to the Shopping Cart list. Instead the workflow copies a Product, on the user's behalf, to this list.
The Shopping Cart List Workflow
The Shopping Cart List has a Purchase drop-down list. The drop-down list includes two options: Keep in Cart or Discard. When the workflow inserts a new list item, it sets the default value to Keep in Cart. The Shopping Cart list was updated to display the "total" based on the Price of each item (which is driven by the quantity of the items purchased). At anytime the user can select "Discard" and save the update. The update action initiates the workflow, which removes the item from the list. The list is managing the total so that when an item is removed the total is updated. In addition, the Shopping Cart List workflow adds the quantity back to the inventory.
Summary
This article outlines how a developer can use content types to reduce development time. And, it explains how workflows can be used to copy a list item in one list to another list. It also provides an overview to the benefits of using Microsoft Office SharePoint Server for custom development projects.
