In the previous article I wrote about wrongness of the SharePoint Mapped Folders, and today I'll try to elaborate this topic and introduce a very good replacement for them.

Are they really so bad?

Actually I'm not quite against Mapped Folders. I don't say they will not work. I don't say you absolutely must not to use them at all... Well, they have limitations and hardly any benefits, but that's not the main problem. The essential problem with SharePoint Mapped Folders is that they allow and even encourage ASP.Net developers to work as they were working in ASP.Net...

SharePoint is a huge 10+ years old enterprise development platform based on ASP.Net. SharePoint relates to ASP.Net as ASP.Net relates to C#... In ASP.Net you don't use pure C# to yield HTML to the page, right? You use markup and controls and page life cycle and databound controls and all this stuff they built for you. Then why do you keep using pure ASP.Net when working with SharePoint?!

Because Microsoft wants to pull you in! :) It sells you SharePoint Mapped Folders, it sells you SPGridView and it sells you the idea: "you know ASP.Net? great, you can develop solutions for SharePoint!". It is really a good bait. But I think nobody in MS really thought anyone can keep jumping at this bait for years :)

In fact it is never enough to know ASP.Net to develop efficiently in SharePoint. You must learn tens of SharePoint features and intended usage and limitations for each of them, and how SharePoint is built and how it works and how it scales. The reward is that the development time is decreased greatly (compared to ASP.Net approach) and you concentrate on UX and business value and make really useful and convenient portals which save a company money rather than devour them...

And returning to the SharePoint Mapped Folders, this evil thing definitely encourages developers to keep ASP.Net ways and essentially - write the same code SharePoint Development Team had already written and tested years ago on thousands of different configurations. It encourages them to code from scratch hardly using SharePoint at all, and it is a great shame when such people name themselves "SharePoint developers" :(

So yes, SharePoint Mapped Folders are really bad if you think about it. And btw, we have much better alternative!

The alternative

SharePoint Mapped Folders is essentially a way to store files, pages, controls and so on. But SharePoint virtual file system serves the same purpose. Why not use it? Even for administration pages, why not?

Create modules, put files there, put modules inside features, that's all. You can either deploy your files into libraries or leave them out in plain folders if you don't want users to touch them.

Important advantage is that you can access your files and pages through SharePoint Designer. You can connect to your customer site remotely and do a quick fix if it's necessary, and you know that some customers don't allow RDP access... You can use versioning and checkin/checkout features, so that first you verify your changes yourself, and only then check them in and make them available to all users.

Comparing site pages (deployed through modules) and application pages (deployed via SharePoint Mapped Folders), the biggest benefit of the former is that you can switch a site page to edit mode, add/remove webparts and so on. You can't do this in case of application pages, they don't support webpart zones and dynamic webparts, and OOTB webparts put straight to application pages markup aren't supported to work there as well (in fact they will work to some extent, but not without issues).

Thus, by having some administration page as a site page rather than application page, you can, say, add a quick announcement by adding Content Editor Webpart to the page, and so on. No need to recompile or deploy anything.

Some other features include versioning and approval (if you deploy files to document libraries), "Revert to site definition", links tracking (see BackwardLinks property of SPFile) and many more. It's a wonder how many interesting features SPFile object includes!

And yes, you perfectly can have code behind there if you wish, by deploying a custom sandboxed visual webpart or a user control there (though in most cases I would prefer to use some OOTB SharePoint controls/webparts).

As you see, there are really many benefits when you deploy files to SharePoint via modules instead of using SharePoint Mapped Folders.

And you will get even more once you start leveraging SharePoint OOTB webparts and controls like DFWP, CQWP, XLV and so on (which by the way are not supported on application pages), and webpart connections, and all other beautiful SharePoint features on your site pages. Based on my experience, OOTB webparts are sufficient for implementing 90% of business requirements, and you can do it tens times faster and the result will be completely integrated with all the rest of SharePoint, which is really amazing! :)

When SharePoint Mapped Folders are better

I honestly tried to think out some use cases when application pages are better than site pages or when having files in layouts is preferrable to storing them in database, but can't! :(

Performance benefits are negligible, and correctly configured Remote Blob Storage allows you to eliminate such benefits completely.

Availability throughout the farm is more disadvantage than advantage, because I assume my page should work only for the sites there my feature is activated. Then you use SharePoint Mapped Folders, you make your files available in every site and site collection in the farm instantly. You just cannot scope them.

Some SharePoint features require adding files to CONTROLTEMPLATES folder (like RenderingTemplates), but most of those features are very old and usually there are better ways to achieve the same goal. And well, a couple of controls in ControlTemplates is OK.

You can use ashx files in SharePoint Mapped Folders, but in most cases you can live without ashx. Last time I used ashx to upload files to SharePoint asynchronously, though I'm still convinced that there was some better way to do it, but we were tough on schedule and so I preferred ashx approach...

Fetching SPContext automatically by current URL is probably the best benefit we have for application pages, though it is not a big deal to grab the context manually from either query string params or HTTP referrer or whatever...

What else? If you have any ideas regarding to that, please drop a comment below, let's discuss. But honestly, I don't see any big benefits in using SharePoint Mapping Folders and/or Application Pages.

Conclusion

I've been working with SharePoint Mapped Folders and creating application pages for about two years in a row, from my very start with SharePoint. But for about 1.5 year now, I've been using modules and site pages instead, and my solutions became much better and I'm able to implement them much faster. I wish you the same :)