Introduction to SharePoint Lists
Starting with Office 2003, Microsoft introduced SharePoint Lists which allow Office client application such as Excel to manipulate lists of data provided by SharePoint. This way users can keep information in their Excel/Access tables synchronized with a list hosted on the SharePoint site. This feature is available for Excel 2003+ and Access 2007+.
CodeFluent Entities can generate Web Services – which can be hosted in IIS or WCF – which emulate a SharePoint server so that Excel and/or Access can be used to edit your data. Since it leverages a Microsoft Office built-in feature, it does not require any deployment on user’s machines. The global architecture is illustrated in the following figure:
As shown in the figure above, using the generated lists does not require SharePoint at all, it only emulates SharePoint as Office applications such as Excel and Access were built to consume Lists hosted in SharePoint. From a developer’s perspective, all server components from the data tier to the web services can be generated by CodeFluent Entities. By default each entity has a list per load method (e.g. LoadAll). Moreover, you can design extra lists by adding views on your entity. By the way, the generated classes are public partial classes, so if you need to create some very specific list, you can always write it yourself without having your code overwritten on a following generation.
Finally, since your generated lists use the business objet model to manipulate data, your business logic is still applied.
In a nutshell, generating Office synchronizable lists for Excel and Access enables end-users to edit and manipulate massive amounts of data in a familiar UI. End-users will benefit from advanced features such as Excel’s filters, sorting and pivot tables or Access’ Form View. Furthermore, it’s all based on a built-in feature which does not require to deploy any component on the client side, nor to actually have SharePoint on the server.