As I have announced in my previous post – I will start a series of the architecture related SharePoint articles on this blog. This is merely caused by the lack of the proper architecture, in a huge number of the SharePoint applications I have seen. That, on another side, has been caused by numerous reasons, but nevertheless: we have somehow come to the point, where it has become acceptable that the front end talks directly to the back end. Say, a SharePoint web part communicating directly with the data in the SharePoint list.
Well, it is not acceptable, not in any other technology, and not in SharePoint.
As I have written before – this series of the articles will be accompanied by a CodePlex project, where all of the staff which I talk about in these articles, will be accompanied with the real, living code. The test solution will be the about the conference organization: if you have ever been to a SharePoint conference, or any other development conference for that matter, you know that there is a lot of stuff to be done – from the speakers’ perspective (speaker bios, session abstracts, session schedule…), but mostly from the visitors’ perspective (applying for the conference participation, registering for a single session, rating a session…).
Of course, we will want to have a nice, modern way of doing things – we want visitors to register to a session simply by scanning a QR code on the door. We want them to be able to rate a session in a nice web interface on the conference web page. Even better, with a Windows Phone 7 app. OK, maybe even with the mobile-optimized HTML5 page (there are still some folks out there which are not using Windows Phone, from whatever reason it might be).
Conference administrators, on the other side, will mainly use the standard SharePoint interface for managing the conference data – visitors, sessions, schedules etc. But we want to make their lives a bit easier – we want them to know the session ratings immediately after the visitors have given them. We want them to know the session visitors immediately after the session end. And we would like to give them a nice geographical distribution of visitors, overview for the whole conference, and for each single session.
This will be our project. As you can see, a lot of work is waiting there, but we have to start somehow.
It is obvious, even now at the beginning, that a solution without architecture would not give us any benefits here. Just consider the task of rating a single session. We have said – we want it to be possible to do that through the web interface. Let’s say – we need a web part for it. Then we have said that we want to make it possible through the WP7 app. And, on the end, we want a sleek app for the non-Windows Phone mobile devices. Should we then develop this logic three times? Once, we talk directly to the SharePoint from the web part. Then we develop the same thing for the Windows Phone. Then we develop a special page which would be optimized for the other mobile devices. Now, that does not make any sense, does it? We need to have one piece of code for rating the presentations. Our web part, our mobile devices optimized web page, our WP7 app – they need to talk to that piece of code. So when we change the rating logic, it’s changed everywhere.
Not to mention, how much easier testing of that code will be when we write it only once. And testing is also kind of important. As we see, it’s all about architecture.
So, how does a generic architecture for a complex SharePoint solution looks like? Well, there is no uniform answer for it. It all depends on the needs of the application. But the next picture can give an overview about some standard cornerstones which should be found in the solution.
We see quite a number of boxes here, even if it is a simplified model. It would be too much, to explain it all in one article, but, let’s just identify here architecture layers we have used in this example:
SharePoint UI Layer
This is all about SharePoint, so let’s start with the stuff which should be well known for most of the SharePoint developers – SharePoint UI Layer. Web parts, ASPX pages, workflows, event receivers…
Wait a moment. Workflows and event receivers are in the UI Layer?! Well, a kind of. Of course they are not really UI, but when you think about it – they actually do a typical UI tasks: they trigger business processes. Of course we can make them actually EXECUTE business processes, but we can do that in a web part as well, can’t we?
You get the idea -a web part, an ASPX page – it is all UI, they don’t do any business – they interact with user, they collect data, and they give that data to someone else to do the dirty work. If we think about our example solution – conference organization – this is where the visitors will give ratings to the sessions. They will see a form, they will enter ratings, and they will click the OK button. That’s it.
This is where the dirty work has been done: we actually need to DO something with the input data which comes here. And yes, we also define our data model here (data entities). If you think from the SharePoint perspective, you don’t want to write a series of strings and numbers (which represent our rating) in the fields of a SPListItem. Of course you can do that, but, then good luck with validation, testing, debugging, and, oh yes – with the maintaining that code. That is the reason why we will have the Rating entity, where we will store our ratings. We will have a number of supporting methods for that rating – to validate rating, to calculate the average rating (not as simple as you think!), well, a number of different things to do. You can’t do that with the values of the fields in the SPListItem object.
And yes, this is theoretically the only layer of the solution which you will never want to replace. You might improve it, you might add some new functionality, but this is the ONLY part of the solution which you don’t want to replace. You can replace the front end – you can develop new web parts, you can develop new interfaces for new devices, but they will all talk to your business logic. You can also replace the back end – your customer might tell you that she has, after a long and painful thinking process, decided that she does not want SharePoint Server on the back end. She wants a SQL Server. You might curse, but you will make a new Data Access Layer, with new persistence methods. Your business logic stays the same. It didn’t change, did it?
Data Access Layer
And this is where you write your data to the SharePoint, and where you read it from there. You don’t do any calculations here (like calculation of the average rating), you simply read and write your data. It is more than enough work for this piece of code.
And you will want to have more than one Data Access Layer implementation in your solution. You will at least want to have a mock implementation, so you can make some isolated tests, without bothering about SharePoint. Or, from the example above, you might want to implement an alternative, SQL Server Data Access Layer. All this can happen. So, this is why you need an interface. Your interface is basically telling what the Data Access Layer has to do, and the different implementations of this interface (SharePoint, SQL, Mock…) will do that. Since this interface is closely related to our business entities, it is stored in the Business Layer, but all of the different Data Access Layer implementations will implement that interface. It might seem odd at first, but it is actually quite handy.
There is another challenge with the SharePoint implementation of the Data Access Layer. It needs to be aware of the context. Well, you might think, but we know the context from the front end – SharePoint UI elements? Yes, we do, but we have the Business Layer in between, and it has no idea about the SharePoint context. Why should it? It shouldn’t even know, where are we storing the data that it is manipulating. And, if you think about it, our WP7 and HTML clients will also not be aware of the context. These are the challenges we will deal with in the following articles.
Data layer is pure SharePoint Server, SQL Server, or whatever we want it to be. In the case of SharePoint, we need to configure it, to create lists and libraries, create workflows, change different settings.
This is where we do our common stuff. Logging, application configuration, exception handling, dealing with localization (a huge issue in SharePoint) and similar stuff. Where are we going to log? ULS is the natural answer for the SharePoint, but what if we want to switch the logging to, say, Event Log, or to the local text file? Do we need to refactor our solution to change that stuff in all pieces of code where we have used the logging? Do we have different logging implementations in the front end and business layer (front end might not be SharePoint-aware)? And how do we configure that logging and the application in general?
All those questions will be dealt with in the infrastructure layer – I can already tell you that it will contain a number of interfaces, and a number of the implementations of those interfaces. And that a huge portion of this series of articles will be devoted to the infrastructure layer.
We need to expose our business logic to the outer world – we might have some quite different client implementations. Some people are still using iPhones. Scary, I know, but that’s the fact. And different clients can have different ways of communication. No problem, we can cover them all – WCF, REST, even the good ol’ ASMX is not quite dead yet (and it is aware of the SharePoint Context). This stuff will be our interface to the world. Whatever might be out there.
This is all UI, which is not the SharePoint UI. And as we have said – it can be a lot of things. Silverlight application, different .NET managed clients, web stuff, interfaces to the other applications, whatever you might think of. Very often you will not even control it – there will be other people and applications who will want to connect to you. It’s all UI for you.
Wait, Silverlight? And managed .NET applications? Don’t we have the SCOM (SharePoint Client Object Model) now? Aren’t we reinventing a wheel with this? No, we are not reinventing a wheel. Or do you want to develop the session-rating logic again in your Silverlight client? And when rating logic changes, you need to change it in two different pieces of code? We don’t want that.
Is the CSOM obscure then? Useless? Not at all. CSOM is a great thing, if you have a LOB application which needs to exchange the data with SharePoint. Or, to use SharePoint’s collaboration features – document storage, collaboration, versioning… This is where the CSOM is your (very) good friend. When your business logic stays in the external LOB application, and when you just need a way to persist the data in the SharePoint, this is the playground for CSOM. But you shouldn’t implement the business logic with CSOM, from the numerous reasons, which were all stated above at least once.
But it is enough for now. In the next article, I will describe our Conference Organization solution, it’s parts, and finally start coding. Until then, cheers.