Introduction to the SPS series - Defining a base class library
So let’s start with something simple. We’re going to define a few base classes, that will be used later on with all of the topics listed in the previous post. The base classes include:
- A base abstract configuration class that will contain some info related to the metadata about the lists with which we’re going to work.
- A configuration factory class, that will provide us with the instance of a class inheriting from the abstract config.
- An implementation of the base config (just a simple hard-coded example).
- A base abstract class, wrapping an instance of Microsoft.Sharepoing.SPList. It will take care of the initialization of the configuration settings, along with providing us with some basic operations like searching for items in the list through a SPQuery instance, and working with the views defined for the SPList instance. Throughout the next following posts (or small articles) we’ll extend the basic functionality of the class, by encapsulating more and more features inside the base class.
Here’s a small diagram, showing the base class, along with some details about the configuration and the way it’s using it:
The BaseList class inherits from System.Object (as all classes in the .NET world). It wraps an instance of the Microsoft.Sharepoing.SPList class and adds some metadata (as properties) relative for that list. The class has 2 constructors – first one listName, of type string and a second, that takes as input the name of the list and in instance of the Path. The Path class is a wrap for 2 properties, we’re gonna need on order to initialize the SPList instance – the address of the portal (the root – something like http://www.microsoft.com/) and a relative path under that root – the address of the sub web, we’re gonna mess with.
Now – why do we need 2 constructors? Well – it’s pretty simple – we’re gonna support more than one way of initializing the list. One way will be by using the list name. When we do that, the list instance will initialize itself with settings coming from the configuration (that will be hold inside the Path instance). Other way of initializing the instance will be with the explicit use of the portal and site path – a case that will apply when we work with a number of lists, and have some sort of a relation between them. Then the second constructor should become very handy.
But where the configuration info comes from? We’ve already mentioned that we’ll be using an abstract base class and will be able to have more than one child implementation classes (for example with a config info coming from DB, a Enterprise Library’s Configuration Application block or some other “data source”).
So here it is:
As you can see from the diagram, the abstract BaseConfig class, is just a “blueprint” – it has only 2 properties (for now). Underneath is the TempConfig – an implementation instance, that simply will return some hard-coded configuration information.
The trick here, is that won’t use the TempConfig explicitly – we’ll return an instance of it, but it will be cast as a BaseConfig – this way, we be able to move to a more mature class (or simply use different configuration, depending on the caller, or the buld we’ve done – using conditional compilation or something else)
And here’s the factory:
All it does, is holding an instance (because we want to stay with a single (singleton) instance for all callers, and returning info from the config “data source”.
That's all for now - more to come soon :)