- Introduce in Sharepoint 2013.
- The solutions Actual execution doesn't happen in sharepoint.
- Apps are execute in browser client or on a remote web server so there is no much load on server farm.
- Code Migration is very easier because most of the App model runs based on Jquery.
- They are granted permissions into sharepoint sites via OAuth and Communicate over the newly improved sharepoint 2013 CSOM API's.
Important Note: We are all know that, JAVA is a plant form independent language, but Do we have such language in web applications ? Yes, we have a scripting language that is Jquery which will run on any browser such as Desktops, Laptops, Smartphones, Ipads ect, So SharePoint 2013 App Model runs based on Jquery.
Farm Solutions
i) Introduced in Sharepoint 2007
ii) Available in on-premise deplymnets in 2013, & some dedicated cloud-based deployments.
iii) Customizations used across an entire farm
iv) Custom code is deployed to sharepoint web application's \Bin Directory or Global Assembly Cache.
v) Code can be secured using .NET's Code Access Security ( CAS ) but typically is run in full trust.
Sandboxed Solutions
i) Introduced in sharepoint 2010.
ii) Available in all types of deployment scenarios.
iii) Solutions are available in all sites across an entire site collection where there are deployed.
iv) These type of solutions are upload and deployed my site collection administrators.
v) These type of solutions impose quite a few restrictions on the developer.
vi) In the Cloud to get around the limitation by using sandboxed solutions
i) There are limited set of operations you can do in the sandboxed solutions.
ii) Sandboxed solutions can't execute for longer than 30 seconds.
iii) They cann't exceed a certain amount of resource usage per day.
iv) Server-Side code can not make calls/requests to externally hosted web services.
Apps Solutions
i) Introduce in Sharepoint 2013.
ii) The solutions Actual execution doesn't happen in sharepoint.
iii) Apps are execute in browser client or on a remote web server.
iv) They are granted permissions into sharepoint sites via OAuth and Communicate over the newly improved sharepoint 2013 CSOM API's.
- Microsoft has several reasons to push client-side programming and remote access in sharepoint.
- Main reason is root cause of most sharepoint performance and security issues has been the server-side code included in farm or sandboxed solutions.
- How many times as a developer have you suffered fromt he sharepoint object model being tightly coupled with a secific versions of the .Net Framework or Window Workflow Foundation.
- Now, You can choose your preferred scripting language ( PHP, javaScript, LAMP, and so on ) or any ASP.Net ( ASP.NET Web forms, MVC, and Web Pages) & Use Remote calls.
- Solution Upgrading is major problem in pre-sharepoint 2013.
- In the new programming model of sharepoint 2013 is on client-side code and remote access.
- Microsoft Recommends that developers follow the new app model as the preferred way of building their custom applications for sharepoint 2013.
- In sharepoint 2013, _vti_bin/client.svc is now aliased with _api, which makes it easier to reach out to the service endpoint. Micorsoft also made client.svc and made it fully OData-compliant service.
- OData is leading industry protocol for performing CRUD ( Create , Read, Update, and Delete ) operations against data. CRUD map to standard HTTP verbs like Get, Put, Update, Delete and Merge.
- OData Pay-Load are based on popular standards such as Atom (For reading web resources) and AtomPub ( For creating and updating resources).
- OData is available for many non-microsoft platforms such as iOS and Android.
