Asp.net-mvc – MVC application inside sharepoint drawbacks

asp.net-mvcknockout.jssharepointsharepoint-2013

We're doing an application which takes feeds and items in that feed to entities on our own site. This is supposed to be an open site which anybody can sign up to. All of this is done with MVC + knockoutjs. We are thinking about managing the entities from that site using Sharepoint 2013, essentially replacing our SQL tables of those entities, and putting them into lists on in our Sharepoint instance. We're also thinking of doing the same thing for users and passwords and such. Then we might have a setup for a single sign on for any other sites my company makes. Currently we're using NHibernate and SQL server.

Are we are naive to think that Sharepoint could handle the amount of traffic, with outside users using our site, along with customers. I've heard that it's doable, I'm just wondering if it's a smart thing to do, and if there are hickups, limitations that any of you have run into trying to do this.

Best Answer

We went pretty far down the Sharepoint-as-a-development-platform path and ultimately ended up scrapping what we had done and rewriting it in other technologies. That doesn't necessarily mean it is not the right choice for your situation, but there a few things to consider:

  1. "Why do it this way?". What are the benefits to adding the Sharepoint layer to your technology stack? If not Sharepoint, what do the alternatives look like?
  2. Do you already have a solid Sharepoint admin team in place? Sharepoint definately requires a dedicated admin or team of admins that really understand the product to keep it performant and to help you troubleshoot when things are not working correctly.
  3. Do you have Sharepoint development talent already in house? Good Sharepoint developers are harder to find and are typically more expensive than your regular .NET developer. Also, some existing .NET developers may not be interested in learning Sharepoint.
  4. What is your expected traffic, and can Sharepoint handle it out of the box? At least in previous versions of Sharepoint there were internal limits on the amounts of data that could be stored in each list. On top of that, there were practical limits before the performance of the app becomes totally unacceptable. Understanding what those limits are should be a part of your initial due diligence so you can plan for those eventualities.
  5. Will you be extracting operational data for external reporting or warehousing purposes? Is your data team already familiar with getting data out of Sharepoint?

Ultimately, the reason we failed was we ran down the path after the promise of "easy" development without really committing to the product. When we started running into problems, we struggled with basics like troubleshooting because we had lost a couple key people and our regular devs and admins struggled to figure out what was going on. If we had had the right people in place, our experience might have been different. We didn't, however, and we eventually chose to move away from Sharepoint and rebuild on our standard MVC/SQL platform.

Related Topic