Hopefully, you now have a clear
understanding of what LINQ is and how it works. We need to use entity
objects that represent the data in our application if we want to use
LINQ syntax. To illustrate the use of LINQ to SharePoint and the tools
for generating entity classes, consider the following scenario:
Your company is involved in renting industrial
machinery. You’re working on a web-based application that allows
customers to view a list of the items that the company currently rents,
together with details of the individual rental contracts. Customers
come from a number of geographical locations and sometimes relocate
equipment from one location to another. To make it easier for customers
to track the location of the rented equipment, your application allows
the customer to add multiple notes for each item, and these notes
should also be visible in your web application.
Note
You
might appreciate a bit of clarification regarding some of the
terminology used here. You non-British readers rent equipment, and
equipment is said to be rented from the company. In the United Kingdom,
we hire equipment, and equipment is said to be on hire when it is
rented. So an “on-hire asset” refers to an asset that can be rented and
is subject to a rental contract (or hire contract).
Since your company has a relatively small number of
large customers, you’ve opted for an extranet solution. Each customer
has a private site within your SharePoint farm that they can use to
assist with managing their account with your company. Since Hire Contracts are standard documents used by all customers, you’ve defined a Hire Contract content type in your farm. Each customer site has a Contracts document library that contains Hire Contract documents. Additionally, you’ve defined an On-Hire Asset
content type that represents the individual item of machinery that is
subject to the rental contract. Each asset has a unique asset tag, and
you allow customers to add notes against each asset tag in a separate
list called Asset Notes. If implemented using a relational database, your data structure would look similar to Figure 1.
A common misconception is to equate a list or
document library in SharePoint with a logical entity in your data
structure. However, this isn’t necessarily the best approach and often
making such an assumption makes you miss out on a lot of the real power
of the SharePoint platform. A more useful parallel is to equate a
logical entity with a content type. Since lists and document libraries
can contain items of more than one content type, and sites can contain
more than one list with the same content type, using lists and
documents libraries to store items is mainly useful for setting
security on a subset of items or for grouping items based on their
status or some other business-specific reason. Bearing this in mind,
when we translate our data structure into a SharePoint model, we end up
with something similar to Figure 2.
Logically, we still end up with the same collections of entities, but
our use of content types allows us to create an unlimited number of web
sites, each with the same structure and permissions to view only the
customer-specific subset of data.
If
you compare this model to a standard ASP.NET application using a
relational database to implement our original logical data structure,
you can see that implementing security and filtering for each customer
would incur significant overhead.
