7

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?

  • 1
    I'm confused why to offer a bounty for this question, because in my eyes it has already been answered. The below answers point out what separates the many "terms" of SharePoint's customization parts (i.e. e.g. add-in, event receiver, webhooks, ...), and as stated, they are something brought among the new versions of SP. Why they don't answer to your requirement is something you still need to address. Be careful on adding any new questions while specifying, because you are already asking 2 questions at once, which isn't recommended. – moe Jun 26 '17 at 12:39
9

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)

  • now for sure i would need an app because I want to develop remote event receivers...another requirements is that the purchase order need to integrate with external systems and the proposed interface itself is wide beyond what i can do inside sharepoint list forms. as i need to have some CRUD operations with interface that allow adding items inside the current order using JavaScript dialogs and also the ability to export the order as PDF and MS word.. i found those functionalities are very hard to be achieved using built-in sharepoint components (mainly the list views and list forms) – john Gu Jun 23 '17 at 16:23
  • so developing this using using asp.net MVC which integrates with sharepoint lists is better and more suitable. so now the questions are :- 1) should my asp.net mvc be a standalone application or a sharepointadd-in? 2) second question should the asp.net mvc web application integrate with sharepoint lists or with its own database? i would integrate with sharepoint list to benefit from permission settings and from auditing/versioning which are provided by sharepoint lists..instead of having to build this from scratch .. what do you think ? – john Gu Jun 23 '17 at 16:27
  • Again, this is a pretty big topic, and you didn't address some of the key concerns I raised. how many tables will your app have? A relational database is challenging to reproduce via SP lists. You mentioned version control, but SQL has a feature than can automatically keep a history of all changes to rows. Re standalone app vs add-in, what specific features of SP are you planning to take advantage of? – Mike2500 Jun 23 '17 at 16:51
7
+75

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.

  • so what are the dated techniques you are talking about in this case? remote event receiver or mvc or ....?? i did not get your point correctly... – john Gu Jun 26 '17 at 13:35
  • 1
    @johnG I refer to anything that has been revised since its release with a new way to implement the same end result. It's a broad definition, but that would be from the oldest to the most recent e.g. farm solution -> sandbox solution -> apps -> SPFx; or event receiver -> remote event receiver -> webhooks. To map MVC along the lines, I'd put it before SPFx although its origins are further in the past. – moe Jun 26 '17 at 13:45
  • the sequence you provide is what i am looking for... but i think you mixed things together... i mean i can not compare App/Add-in to webhooks ... while i can compare Event Receiver to Remote event receiver to webhooks is this correct? – john Gu Jun 26 '17 at 14:11
  • so if i want to implement something that fires when items are added such as change the item priority to high if it is created by users inside a specific group (inside SP on-premises or inside SP online),, i need first to consider webhooks then remote ER then server side ER ?? is this point correct ? – john Gu Jun 26 '17 at 14:12
  • 1
    @johnG I might be missing myself where I had mixed comparing apps with webhooks, but you got it right that event receivers would be a dated alternative to nowadays' webhooks, whereas apps find their counterpart in SPFx. And yes, based on that example: correct. – moe Jun 26 '17 at 14:14
2

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

  • 1) Your provider-hosted add-in comes with 2 projects. One project generated a package to deploy onto SharePoint and second project is a remote web application which is your MVC application and this should be host on IIS. 2) The MVC application can interact with SharePoint Lists/Libraries and at the same time, it can interact with external sources. – Venkat Konjeti Jun 23 '17 at 16:45
  • thanks for the reply, my question is when/how to use MVC inside sharepoint,, now i already know the info you provide in your question ,, but my question was on how/when/why to use each appraoch mainly :- 1) developing the MVC as a standalone or as an add-in? 2) when to try to customize the built-in SP forms and features , and when to develop everything using MVC ? – john Gu Jun 26 '17 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.