An ex-colleague used to say that SharePoint = Share the pains, and he’s mostly right 😀 – particularly around rapid development, debugging and testing. 

I have found one particular approach that can greatly lessened those pains, and that is to move as much code into a business layer, and make as little “contact” with the SharePoint platform as possible until the end of the dev cycle.

As an example, let say you were developing a feature that when activated will change the title of a list. This feature will require a feature receiver. You could write a class that inherits from SPFeatureReceiver, and in this class do what you have to do:

public class ChangeListTitleFeatureReceiver : SPFeatureReceiver
{
        public override void FeatureActivating(SPFeatureReceiverProperties properties)
        {
            //Get list
            //Change list title
        }
}

This class would then be referenced in your feature XML as the receiver.

Consider the pains here:

• Hard to isolate problems – You are mixing both XML and code. If something goes wrong, is the problem in your code? or the XML? or the SharePoint instance you are deploying to?
• Development is painfully slow and tedious:
  • Assembly needs to be re-GACed and app pool needs to be recycled if you want to see the effect of a code change – this will cost you at least 20 seconds each time.
  • You need to attach to process to debug.
  • Hard to repeat code/compile/run cycles for testing and debugging – because you have to restore SharePoint to a good state prior to each run, in this case it would involve deactivating feature + reactivating feature.

A better approach is to move the logic into a business layer, e.g. the ListTitleUpdater class:

public class ListTitleUpdater
{
        public void ChangeTitleForList(SPList list)
        {
        }
}

The responsibility of this class is to update the title of a given list. It does not need to know whether this is being done as part of a feature receiver or a button click on a page.

The idea is then you would develop and test this class in isolation, free of the SharePoint platform, using a console harness application. Only when you are completely satisfied/confident with it, you would then wire the feature receiver class to the feature through XML and invoke this class from the feature receiver class:

public class ChangeListTitleFeatureReceiver : SPFeatureReceiver
{
        public override void FeatureActivating(SPFeatureReceiverProperties properties)
        {
            //Get list
            new ListTitleUpdater().ChangeTitleForList(list);
        }
}

What is the benefit of this approach?

• Isolation of problems – you can largely eliminate XML and the SharePoint deployment infrastructure as the cause of any peculiar problem.
• Quick and painless code/compile/run cycles – as you have removed the SharePoint infrastructure, you do not need to re-GAC or recycle the app pool. You also do not need to deactivate + reactivate feature. The console app will also launch much quicker than your SharePoint instance.
• Easy to debug – no longer need to attach to process.

Other benefits:

• Encourage better design and architecture – this is a layered architecture approach. The business logic will be more reusable and better protected from requirement changes.
• More testable – because the business logic resides in a separate class, it is much easier to write unit tests for. For example, you can instantiate it and mock the list parameter easily.

Yes, you cannot avoid XML and will have to make contact with the SharePoint infrastructure eventually. The point is though, this can be very later on in the dev cycle, and 90% of the complex logic will be developed and tested in a stand-alone class.

Yes, Visual Studio 2010 makes the F5 debug/run experience a little nicer, but it will not be as fast as doing so from a console harness program.