Transactional behaviors in Sharepoint

I know some sharepoint developers would say “Are you kidding me ?” when read the title of the post, yes I know sharepoint is not recommended to implement transactional behaviors, this is for particular situations for example Imagine an situation where an action in your form implies to execute three operation at business level, for example image that with a click in a submit button you should to insert a item in a list, update an existing item in another list and finally load a document to document library. Now imagine that you develop this functionality and everything is nice until your QA team makes some nice tests and discover that some times that code is breaking in the last operation, I mean loading the document in the document library, so you notice that the transaction is incomplete and this makes your software unstable. If we were working with a Database get a solution for this issue would be very easy using transactions, rollbacks and commit, but Sharepoint does not support the use of transactions natively.

So Im going to describe the way that our develop team is avoiding this kind of issues. Basically we are emulating transactions using the most simple design pattern we know, the  command pattern. Steps below show how we implement transactions in Sharepoint

Creating a base command clase

The command pattern is one of the most simplest patterns and its based in an interface and our approach with this pattern is to separate all the operations of a transaction in classes that should implement the base interface, using this approach we will have command classes  that are responsible for execute a command and also undo the command if some exception is thrown. Figure 1 show the implementation of the base command class.

Fig. 1

As you can see this interface only has two methods you can add more if you need, for example some times is necessary a validation after execute the command so you can add a method called Validate() to validate something before execute your command, next step is create all the commands, for this example Im going to base my code in the description of the problem at the begin of the post, so Im going to implement the two first commands creation of an item in a list and update an existing list, figure 1 and 2 show how this classes would look.

Commands Implementation

Fig. 2

Fig. 3

Transaction Implementation

The last class is the transaction, this class basically is a command too, the difference with the others is that this command will be responsible for the execution and undo of the commands if is necessary of the other two commands.

Fig. 4

Fig 5.

Fig 4 and 5 is the implementation of the transaction. As you can see the execute method is responsible for the execution of the other commands and after the execution of each command the executed command is stored in an stack this is because if something is wrong and an exception is thrown the undo method of the transaction needs to know what commands have been executed. I really like this approach because is simple and in addition of the undo possibility for a transaction, this approach help to organize the code and makes the code legible and more maintainable, I hope this would help in your SharePoint projects, I will be appreciate any feedback about this approach or another approaches to make SharePoint work with transactions in SharePoint.