Subclassing SharePoint Objects

Question

Hi,

I want to subclass some SharePoint objects, such as SPSite, SPWeb, SPList, and SPListItem. Any idea how to do it? I cannot create an instance of my derived class since I can't construct the objects with a constructor.

I usually used a container class to wrap the said objects, but I don't think it's a good solution since it doesn't provide a good semantic and OOP-feel to the objects. Any help or suggestion are appreciated.

Thanks.

Answer 1

I recommend not to subclass the SharePoint objects, as I don't see any use for it.If you are going to subclass the SharePoint objects just to add or override couple of methods, try using the Extension Methods of .NET 3.5. That should help you.

Answer 2

Hi Alex, that's correct, I want to derive the standard SharePoint objects and extend it to add my own methods and fields. For example, I have a custom list definition called Order. Instead of doing procedural like:

SPListItem item = new SPListItem();
item["Title"] = "Transformers DVD";
item["Price"] = 30.5;
item["Qty"] = 2;
item.Update();

The OOP-way should be done like this:
Order order = new Order("Transformers Movie", 30.5);
order.SetQuantity(2);
order.Save();

Something like that.

Answer 3

Well I would view the SPListItem similar to the Row in a Table, than an Entity. To push a data to DB we will have a DB layer that handles all the DB related Stuffs and Passing data happens through Entities. Above code can be rewritten as below.

class Order{ 
    public int Price {get;set;};
    public int Qty {get;set;}; 
    public String ItemName {get;set;};}
class OrderHandler{
     Order m_Order=null;
    public OrderHandler(Order oEntity)
    {
          m_Order=oEntity;
    }

    public void Insert(){
       SPListItem item = new SPListItem();
       item["Title"] = m_Order.ItemName;
       item["Price"] = m_Order.Price.ToString();
       item["Qty"] = m_Order.Qty.ToString();
       item.Update();
    }
}

I am quite sure that there is nothing wrong in this.

Answer 4

I agree with the sentiments of other posters that sub-classing the types in the SharePoint object model is a bad idea. My biggest reasons for doing so are:

• the way that SharePoint intrinsically disposes objects based on the context they were created in.
• you'd be creating a type hierarchy based on subtypes that aren't under your control.

The dispose issue is probably the biggest deterrent.

Inheritance isn't always the best solution in sticking to OO principles. An object hierarchy has it's downsides too when it comes to maintenance.

It sounds like you've already explored encapsulation which is a perfectly valid OO approach and would be preferred over inheritance (in my opinion):

public class Order {
    private SPListItem listItem;
    ...
    public Order(SPListItem listItem) {
        this.listItem = listItem;
    }

    ...

    public int ItemName {
        get { return listItem["Title"] as string }
        set { listItem["Title"] = value; }
    }
    ...
}

One problem with these approaches (inheritance and encapsulation) is that they couple your objects to the underlying data store (SharePoint in this case). This may or may not be a bad thing depending on what you're trying to design.

An alternative approach is keeping your code separate from the underlying store and using a repository to handle getting and updating objects in the repository. At least any coupling to SharePoint can be handled by a single repository type, and you can put an interface around it to allow you to use other repositories (either for future scenarios or for testing).

It all depends on your use case and how much your code and platform may change in the future.

One nice, lightweight approach is in Chris O'Brien's blog (Simple data access pattern for SharePoint lists). If your needs match up with his it's a practical way to go.