Posted oI’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:

1. 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.
2. You can design and work directly with a proper SQL database. No Query Throttle Limit.
3. 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.
4. MVC is more amenable to automated testing and lifecycle management. SharePoint is harder in terms of lifecycle management, and downright awkward for unit testing.
5. MVC is much lighter. SharePoint requires a lot of hardware to work well.

There are a few disadvantages too:

1. 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.
2. 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.
3. 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.
4. 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.

No brain-dumps or anything here; if you want the answers, go and bloody study. However, it’s worth knowing about the structure of the exam.

Right, so this is one of the 4 exams you’ll need for the MCSD SharePoint Applications. We decided to fling me at this one without preparation – I’m a SharePoint developer, so shouldn’t I be good at this one without lots of learning?

The Core Solutions exam focuses on the core stuff that you’d get in SharePoint Foundation. There was no search, BCS, Access Services, Excel Services, Visio Services, Secure Store, or any of that Enterprise edition stuff, which was a relief.

Like the ASP.NET MVC exam (yes, I did that recently; I’ll come back to it), this one consisted of some case studies – 4, in fact – plus a set of 22 questions that can be about anything. They were presented to me as 2 case studies, the 22 questions, and the other 2 case studies. Count the case studies as you do them. I thought that by ‘4 case studies’ it meant ‘3 case studies and a general questions bit’, then lost count mid-way, and then got a bit of a shock when I had 2 case studies to complete at the end. I thought the general questions would finish it, but they were in the middle for me. Time did start to become an issue, which is a first for me in a Microsoft exam.

The case studies are a lot of work; there’s a lot to read through, but some of the questions require you to have pulled together details from different parts of the information provided. I think if I’d just scanned the documentation after I’d read the questions, I’d have missed some of the details I needed. Reading the case studies is time consuming, though.

I found the first case study a right pain, but it did get easier thereafter.

General areas that seemed to get a lot of attention:

• Apps – App Licensing, App Permissions (i.e. the perms granted to an app), how to add/remove/uninstall an App, how to control who can add an app to a site, different App hosting models – all the stuff in the syllabus, really.
• Claims Auth – Lots and lots about this, particularly in the case studies. I didn’t do so well at these; this is worth more attention for me in the future. Claims auth, OAuth, etc..
• Workflow(!) – For some strange reason, there was quite a lot about workflow in this exam.
• Packaging Solutions – how to package and deploy a third party assembly, importing solutions you created with SharePoint Designer (Workflow) and by other means. This was a bit weird – I’m just used to writing solutions from scratch, not deploying third party code, but I guess it’s good to know.

All in all, there was a fair range of topics – it was very broad. I found my background in the previous versions of SharePoint useful, and the prevalence of Apps and Claims Auth will hardly be a surprise to anyone, and all the above are on the syllabus.

Oh, and there were questions about the Sandbox and Autohosted SharePoint Apps, which was a bit weird, as these are both deprecated now. I was lucky enough to know the basics about both.

And yes, I passed. It wasn’t a bad pass, either. 4 down, one more exam to go.

Off topic a little for SharePoint, but we all know the value of a Content Delivery Network (CDN), right? In particular, using services that host commonly used files, like jQuery.js, etc.? This has the advantage that other sites that use that CDN may have already cached that file in your visitor’s browser, but it also reduces the bandwidth used by your site.

Well, I found that my site was spending a lot of bandwidth serving jQuery.

Yup, 10% of my site’s bandwidth was being spent on… serving jQuery. That’s not efficient, so I found this post, which describes how to make the site use a CDN instead. Note that the functions.php file it mentions is the one in your theme.

Hopefully, that’ll reduce the bandwidth used. I also changed the css files for the theme, by minimising them; that should save another 200Mb per month. In total, that should be about a 12% saving on bandwidth.

It’s funny how this all mounts up!

Following on from customer related issues in Office 365, there are a number of technology issues that give me concern. I will caveat this that this is based on my last project, and by the time I write this the Office 365 SharePoint platform could have changed to address some of these problems.

Technology Issues

No options for dealing with Query Throttle Exceptions. Consider this – you’ve been using a list for a while, and have lots of useful data in it. Suddenly, some of your views start to return Query Throttle exceptions. You’ve just tipped over the magic 5000 items limit in a large list. What do you do? Well, in normal SharePoint you’ve a number of options, the main one being to create an index or indices on the list so that your queries can be more efficient, and thus avoiding throttling. However, that action is itself throttled – so you’d have to either a) get a Farm Admin to do it, or b) have to define a “happy hour” window late at night when throttling was turned off, and add the index during that window.

The problem is that neither of these options are available in Office 365. You don’t have a Farm Admin, and you don’t have a happy hour. One might expect that you could raise a ticket with Microsoft and that their support would be able to add an index for you – but we (or rather, our customer) tried this, and Microsoft said that they couldn’t. Essentially, if you’ve not got your design exactly right and you want to make changes to a list that contains 5000 items or more, you’re fucked.

As this includes changes like ‘Adding a new column’, which isn’t that rare an activity, this is a show-stopper for me. Hopefully Microsoft will introduce some approach for dealing with this.

Search Latency in SharePoint Online can be very long. I blogged about this previously, and I still don’t think that your typical business user would expect to wait 8 hours for new content to get indexed. I mean, in an on-prem SharePoint system the Continuous Crawl kicks in every 5 minutes – that’s more like the timescale we need. Worse, this compounds the problems with large list queries described above, as it makes it difficult to use the Search Service (which is probably better suited to that kind of query) instead.

Browser Support. Office 365 will no longer supports Internet Explorer 8. This is unfortunately, because although IE8 is junk, it is still used by a lot of our customers. In short, they’ll lose the ability to not upgrade their browsers for years on end. (I might rejoice, but from their point of view it’s an expense with little benefit).

Logging and Fault Diagnosis. Essentially, Office 365 doesn’t have any. Take a moment, and read that again – Office 365 doesn’t have any logging for fault diagnosis. There is a PowerShell API for retrieving log information from SharePoint Online’s logging service – but the only thing that writes to the log is Business Connectivity Services.

It’s possible that Microsoft have more access to logs than we do – I did wonder if the issue is that all customers sharing a tenant machine would be able to read each other’s ULS log entries – but the point remains that we have very limited logging information to go on. Mostly, it’ll just be the standard error message “An exception has occurred”. Great.

Reliability. Which developing with SharePoint online I found I was getting more errors than I’d expect to see. For example, when migrating documents using the client side object model, I would occasionally receive errors like “The server did not respond” which I don’t expect to see normally. Browsing around was similar – you’d occasionally get “Server did not respond” errors. And sometimes I’d see weird transient errors that I couldn’t repeat, such as problems changing the appearance of a site. Now, these problems might not be due to the platform itself – I sometimes question our Internet connection – but still, reliability was worse than having our own server on the same network.

No easy way to do ‘Timed Jobs’. You know how it is, sometimes you just want to be able to perform a timed job for something. For example, it might be ‘Archive completed tasks and the end of the month’. There’s no easy way to do this, though. I’ve had a play with using Azure Scheduler to perform such actions, and it kind of works – but it was hard to get working, and password expiry breaks it. I really miss timer jobs.

Unconvinced about Apps. To be honest, that could be a post of it’s own, so that’s what I’ll do.

Conclusion

I suppose my conclusion is simply that there are a number of issues with running SharePoint Online projects, and I might not rush to do too many projects in it. In particular, the lack of ways of handling the Query Throttle, and the surprisingly long search latency are, to my mind, major issues. SharePoint online might still be a good way of doing your project – but caveat emptor.

We recently completed another Office 365 project, and I must confess, I’m still not sure about it. The project was reasonably successful – but there were a lot of tears shed, and we still have issues that are proving alarming difficult to deal with.

Broadly, I think, these issues can be broken down in to two categories – problems with the customer, and problems with the technology.

Customer Issues

I suppose that many of these are normal for projects, but there are a few that stand out as particularly Microsoft problems…

Nobody gets that the different Plans are. Our customers don’t get it, our salesmen don’t get it, I don’t get it. You’ve Office 365 P (*), K1, K2, E1, E2 (*), E3, E4 plans, Small Business, Small Business Premium, Midsize Business, Government, and Education variants. And the SharePoint Only P1 and P2 plans, not to be confused with the Office plan. (Though those marked with * might be retired). Anyway, it’s too damn complicated, and it makes selecting the right plan a drag on the project – and customers do get it wrong, bless ‘em.

Whose responsibility is out-of-the-box functionality that doesn’t work properly? In every project I’ve done in Office 365 there’s been some feature or functionality that a) doesn’t work, b) doesn’t work as expected, or c) is so damn complicated nobody can figure out what ‘working’ would be. In an ordinary SharePoint project, I might have to build some work around for it – but with SharePoint Online my options as developer are very limited. Raising tickets with Microsoft usually gets a response of “That’s how it is”, which is, at one level, fair enough. However, at another, the customer just wants a working system, is paying me a lot of money, and it’s hard for them not to blame me for some element of SharePoint that isn’t working as anybody expected. I do not feel excited about getting into this situation.

Customers get confused about wanting “Off the Shelf” – but expecting bespoke functionality. This one does baffle me, but somehow our customers are led to believe that Office 365 will do whatever curious things they want “Off the Shelf”. I’m mystified how it happens. At least if they’re developing a bespoke system they recognise this, but for some reason Office 365 does seem to exacerbate this.

It’s cloud, so you don’t have to worry about Infrastructure.” This seems to be a favourite idea and it can be true. As long as you’re not worried about your bandwidth to the Internet. And you’ve thought of having redundant connections, preferably leaving from the other side of the building, and connecting to a separate exchange, run by a separate supplier. And that you don’t want to synchronise or link your user’s AD accounts to Office 365. The advertising makes it sound like it’s like creating a Hotmail account – and it can be. But in reality, there are a lot of other aspects to it that probably mean you want to involve IT…

In part II, I’ll look at the technology issues.