When/How to use asp.net MVC inside Sharepoint on-premises and Sharepoint online

Question

I know in SharePoint things can be done in many ways and using many technologies. But now I am a bit confused on when/how I can/should/most-appropriate to use ASP.NEW MVC inside SharePoint on-premises and SharePoint online. I can find many tutorials on the web which show how to perform CRUD operations inside ASP.NET MVC web applications which integrates with SharePoint lists, and where 2 technologies are being used to access SharePoint (mainly SharePoint lists):

1. CSOM.
2. REST API.

and 2 ways of using ASP.NET MVC (this what most confused me):

1. create the ASP.NET MVC as a stand alone application, as mentioned on this link YouTube link
2. create the ASP.NET MVC as an Add-in inside SharePoint.

Now I do understand that accessing SharePoint lists can be done using CSOM or REST API or other approaches, and it is a matter of preferences/knowledge on which technology to use.

But using ASP.NET as a stand alone application or as an add-in is what confused me. So my questions/concerns are:

1. When to use ASP.NET MVC as a stand alone or as an add-in inside SharePoint on-premises and SharePoint online?

2. now let say i receive a requirement to build a purchase-order module inside SharePoint, so in this case 3 approaches will come to my mind:

   1. using SharePoint list forms (create, edit, view) + Event Receivers (remote or server side) + adding some JavaScript libraries such as SPUtility to hide, show fields inside the forms.
   2. develop the purchase-order using a stand alone ASP.NET MVC, and using CSOM or REST API I can add, edit, view lists items.
   3. Develop a SharePoint add-in using ASP.NET MVC.

So can anyone advice on my above 2 concerns? In my case I have a team with experience in SharePoint + ASP.NET MVC. So from technical perspectives we can deliver the above 3 approaches, but we can not decide on when/how we can/should/most-mppropriate approach to use to develop the purchase-order module?

Answer 1

This is a pretty broad question. MS has released different development frameworks over the years. Each time, they'd say the current was better than the last (though sometimes that's been debatable). For example, you mention event handlers and add-ins. Event handlers were the recommended approach in 2010. remote event handlers were recommended in 2013, and add-ins were recommended in 2013. Currently, in O365, we have webhooks instead of remote event handlers, and we have SPFx instead of web parts or app parts. (app parts are one variety of add-in that can be created).

But before proceeding, I'd back up and look at what specific SharePoint functionality you're trying to take advantage of. If the reason you're creating a SharePoint app is because management told you to create a SharePoint app, I'd rethink it. Does that make sense? If what you're trying to do can mostly be done via SharePoint, then perhaps write a little code to complete the requirements that can't be done via SharePoint. If you're building an app that uses a relational database, do not create that as a set of SharePoint lists. Instead, use an actual database.

So:

1. Is there a business requirement to build the app in SharePoint? If so, what are those specific requirements?

2. Will building the app in SharePoint make the app easier to build and/or maintain?

edit:

A couple of the benefits of an add-ins are authentication and context. Authentication: The add-in has boilerplate code that allows you to confirm that the user has already authenticated with SharePoint. Along with this is the ability to know the context, which is that in an add-in, you know which site the user was on before navigating to the add-in site (the mvc site). (One more detail which is pertanent here is that add-ins are usually installed to each site, where needed. So if there are 100 sites, the add-in could have been "installed" on 10 of them. Sites where it's installed, it will show up on the list of site contents.)

A stand-alone site could be just an MVC site that connects to SP. The application would need to have credentials to get to the SP site, but the user may not need to have an account in SharePoint.

For example, I built a site for an HR dept to allow them to post FAQs and such to the company intranet. The intranet is an ASP.net site, while the HR dept wanted to use SharePoint, as they knew how to use it and loved the list functionality. So a couple users (HR) used SharePoint to populate content, while everyone else used the standalone site to view the data that HR had entered. In this case, we didn't need the non-hr users to authenticate to SP, nor did we need any context info.

Another example, a client gave me a list of requirements, 90% of which could be completed with SP OOB functionality, such as document version control, workflow, etc. So we built the application in SharePoint, and added a bit of code to complete the remaining requirements. In this case, users of the application would be going to the SP site to do anything with this project, and so any code would need to know who they were, which SP groups they were in, etc.

When to use lists? Again, when it's a good fit. For example, MS wrote a white paper a number of years ago that shows developers how to work with large lists. The list that was used in their whitepaper had 100,000 items. In SP, that's a list that's large enough as to require special care and feeding. But go ask a DBA if they've ever had to deal with a table that had as many as 100,000 rows, and ask them how they mitigated performance issues, and they'll laugh at you. (to make sure my comment is understood correctly, I'll add the obvious point that 100,000 rows is not a "large" amount of rows to any database platform)

Answer 2

Expanded my 2¢ a bit from a comment I afterwards withdrew.

I strongly support what @Mike2500 has said:

If the reason you're creating a SharePoint app is because management told you to create a SharePoint app, I'd rethink it."

Now when you have decided that an app is needed, go with the one that's intended for the product you are using (SPO: SPFx, webhooks; SP2013: add-in, remote event receivers; SP2010: ...). That's the supported development for the product you are using, thus the most recommended way to go.

Seeing how features of SP can be scrapped out already between major versions (e.g. 2013 --> 2013) calls for responsibility when planning to use techniques introduced in the past releases (releases older than the current, i.e. SP2016). Microsoft does keep a note of the planned/about to be added/cancelled features at Office 365 Roadmap, which may be used as a source for planning new implementations. Equally one should refer to the Office 365 Planned Service Changes for 2017 – Admin Action Required when you are about to use dated techniques.

It's indeed a topic to debate why not to use e.g. the widely learned SP2013 app development skills with SP2016, when SPFx is somewhat hard to use, and you can't be sure what's the skill of tomorrow. However, with SharePoint (as from dev's/admin's perspective), that's what it has been and possibly will be. Actually, the real debating comes in when we should question whether a developer should adapt to this pace of major changes.

That, again, leads to the bottomline of the answer I'd like to emphasize:

When you choose to use dated techniques, you also understand how the solution might not work a year or three from here. But, if your requirement can't be reached using the technologies/techniques targeted for your SP version/product, you should rely on the most recent way available which is capable of reaching your goal.

---

Update

After a lengthy, slightly wandering discussion in the chat about what we started in the comment section, there actually was something to add to the answer exactly to the original question.

When to use asp.net mvc as a stand alone or as an add-in inside sharepoint on-premises and sharepoint online?

Someone more seasoned developer has shared thoughts about this at ASP.NET forums as following:

SharePoint has a limitation in developing some types of business solutions

That would be customizing it which is nowadays not seen as a good practice. Simply create an ASP.NET application (any flavor you're familiar with) and interact with SharePoint/O365 and use it for what you can use it. It's very easy to overuse it and get into a pile of misery when you try to upgrade later on.

And the second question:

now let say i receive a requirement to build a purchase-order module inside sharepoint , so in this case 3 appraochies will come to my mind:- [...] so can anyone adivce?

Similarly quoting the above reference:

Since like last year we've been seeing, and hearing from Microsoft, to don't take that path [customizing SP itself] anymore and simply create SharePoint add-ins in the form of a web application which calls out to SharePoint. Either this can be done with REST calls, CSOM or with the new Microsoft Graph (not only SharePoint

So if I got it right, that would be like your second option. To add, I'd expand this with a "when not to use"-aspect, which would nowadays be when you are able to use SPFx for the same end result as you'd get to with MVCs.

Answer 3

In the SharePoint on-premises/online the custom feature development can be done in different ways.

Farm Solutions

In this approach, you can implement the solutions using server-side object model and deployed as a farm solution. These solutions can be added anywhere in the farm as per the scope.

All code in full trust app runs in SP’s own server process so any corruption has the potential to crash the entire farm.

Any slow/inefficient code has the potential to increase CPU cycles, memory usage leading to affect servers performance.

SharePoint Add-in

This approach to overcome the above problems. These apps won`t use the server context. There are different App-models here to consider

• SharePoint-Hosted Add-in : In this approach all the assets will be store in the SharePoint App context. You can`t use the server side code here and everything is JavaScript based solution.

• Provider-Hosted Add-in : You resources will be stored in outside the SharePoint and can be hosted as a separate web application. You can use Client and Server side code. You can connect with any external system.

When you create a Provider-hosted Add-in solution you get a package to deploy onto SharePoint and a remote web application to deploy in IIS. The package deployed in the SharePoint is a starting point to open your web application hosted in IIS. You can choose the ASP.Net or MVC as a preferred technology as a .Net developer

You will find more information in this article