8

For designing solutions I am confused with whole Apps concept in 2013.

What is Microsoft's guidance for when to use a SharePoint app and when to go for a traditional client or server object model solution? What is the advantage/difference of SharePoint Apps over the traditional object model?

  • 1
    I'd like to hear from someone who's done actual scalable solutions to real problems with App technology, as opposed to pasting in marketing copy from MSDN – Derek Gusoff Apr 2 '14 at 15:44
  • Using Apps is very bay idea, I believe. Apps can be placed in the store and easily replicated through it. Apps severely limited. Good explanation you can read here: blogs.msdn.com/b/uksharepoint/archive/2013/03/25/… – Alexander Ulmaskulov Apr 2 '14 at 15:53
  • We can see what people say . The buzz of apps and later Apps are depreciated in SP next version . – Nikhil J Apr 2 '14 at 15:53
  • I think this should be re-opened. Microsoft has provided concrete guidance on this and it's even a sub objective of the 70-488 exam (choose appropriate APIs). – Robert Kaucher Apr 3 '14 at 1:18
  • @RobertKaucher, using the correct API:s is not the same as using apps or not. In a non-app solution, all the API:s are available. To build an app or not, is solely based on the situation and requirements at hand (but Microsoft will tell you to always build an app when not impossible) – Robert Lindgren Apr 3 '14 at 6:03
3

Apps are subject to certain restrictions, so there are concrete instances of when Apps are not a valid choice for your solution. Here are the limitations I am aware of regarding SharePoint Apps:

  1. You cannot use any non-declarative code other than JavaScript. So if you need to use the Managed Client Object Model for your solution, you cannot use a SharePoint App.
  2. If the deployment in question is on-premises, your infrastructure needs to be able to support the required DNS infrastructure.
  3. Your App webs cannot use Kerberos. Because of the use of dynamic DNS naming of App Webs the ability to create SPNs for use with Kerberos becomes unmanageable. If for some reason you solution requires Kerberos, you are not likely to get it working in an App deployment.
  4. Apps are subject to the restriction of using the JS Client OM or REST. So the same restrictions apply to Apps that apply to using any sort of JSOM/REST-based solution. For example, you cannot interact with the User Profile Service in any form other than read only with the exception of the user's profile picture.
  5. If you are using BCS, you can only use OData connections in the App model.

Under what circumstances would you want to use SharePoint Apps? Many of these have been mentioned by Robert Lindgren and I won't repeat them all here.

  1. If you have an external web application that you would like to take advantage of or you have skills in non-.NET language you wish to take advantage of, you should consider a provider-hosted app model.
  2. If you are concerned about reliability and scalability of your solutions. Autohosted apps should be considered if your project would require that each instance of the app have its own isolated backend web application or data store.
  3. If you have very specific requirements regarding security, you should consider the App model. Apps have their own security model for authentication and authorization that differs from the normal SharePoint security model.

Apps for SharePoint have permissions just as users and groups do. This enables an app to have a set of permissions that are different from the permissions of the user who is executing the app.

You must request, in the app manifest file, the permissions that an app needs to run. The user who adds the app must grant these requests, and the user can only grant permissions that he or she has as a user. The grant must be for all the requested permissions or none of them to simplify the management of permissions for users and developers. (The app principal always has full control rights to the app web, so it only needs to request permissions to SharePoint resources in the host web or other locations outside the app web.)

From Important aspects of the app for SharePoint architecture and development landscape

While many of the reasons you might might actually choose to use or not to use an App are opinion based, there are some concrete issues that need to be taken into consideration regarding the limitations of the App model itself, maintainability of the application, and your requirements regarding security.

| improve this answer | |
1

Here is Microsofts guidance:

The most important guidance we can give you is to develop an app for SharePoint instead of a farm solution or NCSS whenever you can. Apps for SharePoint have the following advantages over classic solutions:

  1. Provide users with the easiest discovery, purchase, and installation process.
  2. Give administrators the safest SharePoint extensions.
  3. Provide you with the simplest marketing and sales system based on a Microsoft online app store.
  4. Maximize your flexibility in developing future upgrades.
  5. Maximize your ability to take advantage of your existing non-SharePoint programming skills.
  6. Integrate cloud-based resources in smoother and more flexible ways.
  7. Enable your extension to have permissions that are distinct from the permissions of the user who is running the app.
  8. Enable you to use cross-platform standards, including HTML, REST, OData, JavaScript, and OAuth.
  9. Enable you to take advantage of the SharePoint cross-domain JavaScript library to access SharePoint data. Alternatively, you can use a Microsoft-provided secure token service that is OAuth-compatible or use digital certificates to get authorization to SharePoint data. (Source)

More about the models and advantages etc. here http://msdn.microsoft.com/en-us/library/office/jj163114(v=office.15).aspx

| improve this answer | |

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.