SharePoint 2013 is a strong development platform for building solutions and apps addressing different requirements and needs.
There’s a plenty of documentation on MSDN and TechNet to get you started with building your first application and how to consume the different capabilities of the platform.
But one thing I struggled to find is when and why you would use a SharePoint App rather than using the object model?
This blog will walk you through that specific question and how to answer it.
Before we start there’s no rights or wrongs here, it all depends on what the customer needs and the best way to tackle the requirements

The Challenges:


1.      Hosting

Solutions

The first factor is where is my code being hosted?
If you are using the object model most of your code will be within the SharePoint host environment:
  • Managed solutions also known as farm solutions will be hosted within the main SharePoint worker process (w3wp.exe).
  • Sandbox solutions will run within the SharePoint sandbox worker process (SPUCWorkerProcess.exe).
If you are using Apps:
  • App code never runs within the SharePoint host environment.
So what difference does it make?
  1. If the custom code is not running within the SharePoint farm this will eliminate any kind of custom operation being done within the farm and hence increase the farm stability.
  2. It’s easier to upgrade if your code is platform independent, we have seen many cases where the customer will hold all the SharePoint migration until he makes sure that all the custom solution will be working fine on the new version.
  3. The deployment, most farm solutions require a Farm Administrator to do the deployment and mostly restarts the IIS on all the WFEs, which causes a disruption in the service. Although the deployment of Sandbox solutions is a lot easier and straight forward but there’s no indication on whether or not it’s safe to activate this sandbox solution without actually activating it and giving the code inside aces to all the site collection’s content.
  4. Office 365 Ready, you can always use Sandbox solutions on Off365, but mostly you would develop two versions from your code one that works with On-Premise farms and another one for Office 365. Now the whole point of an App is you don’t worry where it’s hosted or deployed as it should behave the same on both On-Premise and Cloud environments.

Apps

Apps are very different from solutions in that they run 100% outside of the SharePoint server, and their custom code executes either within the context of the client browser or on other servers that are not running SharePoint such as Web servers in the cloud.
There are three high-level types of SharePoint apps:

  • SharePoint-Hosted: These types of apps are manifested within SharePoint generally without external dependencies. Any custom business logic implemented with custom code must run within the context of the browser client. Some examples of these types of Apps could be an expense calculator or holiday request. Each of these Apps may implement its own business logic using JavaScript, but they can also access and leverage SharePoint lists and libraries.
  • Provider-Hosted: These types of apps may have a SharePoint component but the bulk of the business logic is manifested in some other infrastructure, such as an external Web server or in the cloud. These types of apps are a good option when integrating an existing event registration or help desk ticketing solutions within a SharePoint site.
  • Auto-Hosted: These types of apps are similar to the Provider-Hosted Apps in that they have the bulk of their business logic and/or data storage manifested externally. What’s different with an Azure Auto-Hosted app is that the app package contains the website & database in the package. When the app is installed in a site, SharePoint handles the automatic provisioning of the database (as a SQL Azure database) and website (as an Azure hosted website) using an account that has been setup by the SharePoint farm/tenant administrator.
One explicit limitation of the SharePoint App Model is that server side code is explicitly prohibited from residing on the SharePoint farm as part of an App. Any server side code that is utilized in the context of an App must be hosted outside of SharePoint either in the cloud or on-premises.
The Cloud App Model provides a loosely coupled architecture for building Apps in SharePoint 2013. This loosely coupled architecture gives the freedom of choice for developers in the technologies they use to not only host their applications, but also the tools they use to write them. Apps can leverage industry web standards such as HTML, JavaScript, jQuery, JSON, REST, OData and OAuth to provide an integrated user experience.

2.      Scopes

Solutions

  • Full trusted solutions can be installed on any scope (Farm, Web App, Site Collection, Sites).
  • Sandbox solution  or partially trust solutions is scope is limited to Site Collections

Apps

  • Apps has two different scopes :
    • Site Scope: in this case the app is installed and launched within the same scope of the SharePoint site.
    • Tenancy Scope: in this case a special SharePoint site is required called app catalog, once it’s installed users from different sites can choose to connect and consume this App.
  • Using the object model whenever we need to scale our solutions either up or out ; We needed to introduce new hardware to the farm that comes with the package of :

3.      Scaling

Solutions

  1. Down time considerations
  2. Cost
  3. High Availability and Disaster recover changes
  4. Monitoring

Apps

  • Using the App model you can always scale your application without affecting the current SharePoint environment.
Have a look at windows Azure Scalability options
http://www.microsoft.com/en-us/download/details.aspx?id=36837

4.      Integration

Solutions

  • Previously our only options to integrate with other applications was rather through BCS (Business Connectivity Service), Web Services or build your own service application, this provided the end users with limited experience integrating with external applications.

Apps

  • Using the new App model there are too many options for the integration from Services to actually implementing a fully customized applications against different products SDK.
  • All the web skills are reusable in building the Apps, to a very good extent you can write a SharePoint app without needing to know a lot about SharePoint 2013.
  • Fully supported templates from visual studio 2012.
  • Device free in terms of the device on which the code runs. The possibilities include a server in the SharePoint farm, an external server such as a server in the cloud, a client computer, and a mobile device.

Conclusion

Always develop Apps whenever it’s possible rather than developing a classic Full Trust or Partially trust solution.
Bear in mind that sandbox solutions are still supported but they will be deprecated.
But first understand that the client object models and the REST endpoints that are available in the App model do not duplicate all of the APIs of the server object model that are accessible in a classic SharePoint solution.
 
For more Information :
Reference documentation
Apps for SharePoint compared with SharePoint solutions
Choose the right API set in SharePoint 2013
http://msdn.microsoft.com/en-us/library/jj164060.aspx#Factors
SharePoint 2013 Development
http://msdn.microsoft.com/en-us/library/jj162979.aspx




http://www.fundoovideo.com/video/30/tutorial-1-what-is-sharepoint-2010-sharepoint-foundation-2010-and-shar