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.