I’ve been studying ASP.NET MVC 4 over the last while; this is the subject of second of the 4 exams required for the SharePoint Developer MCSD, and I really need to spend some time on that.
The idea of an MVC (Model-View-Controller) framework is to separate the different concerns of your code, and that usually this allows you to design a data model, and then let your tools create a scaffolding of your site. Such things aren’t new; I implemented a Chinese Chess web site in Ruby on Rails which uses this approach in 2005. I loved the MVC approach.
Still, it’s nice that ASP.NET has caught up, and that it’s intended to take a lot of the labour out of creating an ASP.NET website, though it is radically different to traditional ASP.NET websites.
In an ASP.NET MVC site, typically, the data model is a bunch of tables in a database, and ASP.NET MVC can then create the classes (Controllers) and forms (Views) to allow you to view a list of the rows in that table, and to create, update, read or delete those rows. That sounds like a lot of what SharePoint offers – lists, and the user interface to modify them.
This set me wondering – are ASP.NET MVC solutions actually a competitor to SharePoint, at least for some solutions? Which would I rather work with? I mean, SharePoint is about lists of things and CRUD operations, and MVC’s Index is about lists of things, and has CRUD operations.
Well, it seems to me that ASP.NET MVC applications have a lot of advantages:
- You can auto-generate forms that are then easily modify. SharePoint forms are a bugger to modify, even with things like the Client Rendering in SharePoint 2013.
- You can design and work directly with a proper SQL database. No Query Throttle Limit.
- Runs under Azure quite happily. Using Office 365 for SharePoint can become hazardous if you approach the query throttle limit, and there are a number of features of SharePoint not available in the cloud version.
- MVC is more amenable to automated testing and lifecycle management. SharePoint is harder in terms of lifecycle management, and downright awkward for unit testing.
- MVC is much lighter. SharePoint requires a lot of hardware to work well.
There are a few disadvantages too:
- MVC requires a developer to create a new view. It’s quick to do, but not like a SharePoint user being able to produce their own ListView.
- In fact, MVC requires a developer for a lot of things. In theory, SharePoint would allow ‘business users’ to create solutions in SharePoint. In practice, I don’t think that this happens very often.
- SharePoint does give you quite a lot ‘for free’. For example, versioning of documents in a library – it’s not rocket science, and you could write similar in MVC very easily, but you would have to do your own. There are loads of examples, but it’s worth noting, a lot of them don’t get used very often.
- I’d really miss SharePoint Search. The Search service is really good for, well, allowing you to search across structured and unstructured data. Making MVC search unstructured data doesn’t sound fun.
I dunno, I guess I just found myself looking at some of the things I’ve been asked to build over the last couple of years and thinking, for the smaller, more constrained-scope projects, that they could be implemented in MVC for less effort than deploying SharePoint, and then trying to eke out the functionality you need from that monster.
I suppose I’d consider doing things in MVC if:
- A system is particularly large scale. MVC will give you more flexibility than SharePoint. And sometimes, 30 million items in a list isn’t enough…
- If the system is particularly small – MVC doesn’t need the elephant of SharePoint.
And, I’ve got to be honest, I enjoyed working with MVC. It’s much nicer than the old ASP Page model. I was quite impressed.
Andy Burns' Blog 
Hi Andrew,
Nice post!
In my opinion, SharePoint is not supposed to replace ASP.NET MVC or SQL Server. If there are more than 30 million items in one list, users should not choose SharePoint.
Coding always means trouble. We need developers to fix the endless bugs, maintain the system, extend it, upgrade it, etc. SharePoint did that for business users. Let’s imagine a company with 1000 employees, which needs to create 2 new sites and change 5 changes every week, how many developers do they need? And how long the business users need to wait to get the functionalities? All sites may need different data/list structure.
Comparing labour cost of developers to license fee, SharePoint is really cost effective.
I’m not sure that SharePoint did away with the need for developers/server administrators to work around bugs, extend it, upgrade it, etc. – SharePoint has plenty of it’s own. SharePoint Online has, perhaps (though that brings it’s own issues). And while coding always means trouble, I’d also say that about SharePoint too!
I’ve also got to say, it’s pretty rare that I come across a SharePoint system where the business users actually do have the right and the capability to modify it themselves. Often it does end up being an IT team or department. I know, that’s losing one of the benefits of SharePoint – but that’s how it usually is.
I guess the thing is that there’s no silver bullet, and yes, it’s not that MVC entirely replaces SharePoint. SharePoint still has advantages. However, I do find myself still thinking that it intrudes on the same kind of field as SharePoint for some ranges of solution.
Andy,
Thank you for the Blog post. As a company, we are wrestling with a similar decision and are leaning more toward the SharePoint implementation. Out of curiousity, have you ever had the opportunity to implement a hybrid approach. In other words, something you needed/wanted was difficult in SharePoint but relatively easy in MVC. Could you implement a view and use it as a web part in SP?
I’ve not actually done much by way of hybrid solutions – but I don’t see why you couldn’t do what you suggest. I guess the hard bit is the authentication end of things, which I guess depends on how you choose to approach that. I would have to do some research to figure out how best to achieve that.