App Model

Developers have more options in SharePoint 2013 than any version before. App Model is center stage. Understandably this has created some confusion and debate in the community. I’d like to suggest another coding pattern to consider in addition to pure App Model which I call “Site Asset App Model.”

Long before SP2013 released, I would add jQuery “widgets” to pages in MOSS2007 and SP2010 with a Content Editor. Upload HTML, CSS, and JS files. Simple and effective. Requires no special infrastructure changes. This approach remains valid and has actually improved with advancements like :

JavaScript frameworks

Angular, Knockout

HTML 5 browsers

REST /_api/ endpoints

ASP.Net WebAPI

Entity Framework

BreezeJS

I might not always use pure “App Model”, but I’m 100% sold on JavaScript front end development and the “from Bricks to Houses” philosophy (http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC404) Call this whatever name you like, but JavaScript coding has advantages for both developers and administrators alike. I suggest coding JS first, then fallback to C# wrapped in WebAPI over HTTP, and finally farm solution WSP as last resort.

NOTE – adding the JS statement “debugger;” can help raise a local browser event. That can be a nice trick to more easily create breakpoints in your editor instead of scrolling the same codebase again with F12. http://www.w3schools.com/js/js_debugging.asp

With SharePoint 2013 and industry movement towards the cloud I’ve been exploring JavaScript as a primary way to develop rich applications.

One common challenge is data access.

With C# I have years of experience with [System.Data] and can perform CRUD against SQL relational databases in my sleep. Open connection, query, data adapter, fill DataTable, and voila! Muscle memory. Second nature. Tried and true methods. However, in the new client side JS world I had no clue where to begin.

People describe Breeze as “Entity Framework on the client in JavaScript” which sounds simple yet has profound implication for the developer. CRUD operations, LINQ style query, navigating primary/foreign keys, input validation, caching, batch updates, and more. That’s a lot to consider and new ideas take time to absorb. Breeze could potentially replace:

ASP.Net (ASPX) web forms

ASCX user controls

InfoPath forms

SharePoint web parts

WCF 5.6 data services

OData

Classic WebAPI

I set out to code an example with a few goals:

Create simple SQL schema (two tables – parent/child – one to many)

Execute CRUD operations in JS against SQL tables

Leverage JS plugins and NuGet “Install-Package” to load third party components

Install-Package breeze.webapi2.ef6

Install-Package breeze.angular

Install-Package angularjs.core

Little code as possible

The whole thing took less than 30 minutes and I edited video down to just 15. I was impressed by how straightforward and easy the process was. Breeze# in ASP.Net MVC for the back end WebAPI controller was nearly identical to the Breeze example code. Add one C# method per entity (SQL table) and Breeze does the rest. The JS front end took a little more time to understand but was also easy to apply. Connect Entity Manager to the Breeze URL and you’re ready for CRUD queries. Amazing! Given how easy Breeze is I would be hard pressed to use OData or manually created WebAPI controllers with C# code to query a database. If you can use Breeze, then use it! You’ll save lots of effort.

I needed a quick reference to introduce developers with the SharePoint 2013 App Model.

For traditional ASP.Net and Dot Net coders there is a wide philosophy gap to cross when considering new applications written mostly in front-end JavaScript, HTML, and CSS. Instead of coding “in” SharePoint (to augment the core product) we now code “next to” SharePoint (with additive REST/JSON endpoints).

The stability which comes from this approach is significant. We wan to run on-premise SharePoint similar to how Microsoft operates Office 365. No more SharePoint customization lost during patching. No more late night WSP and IISRESET outages. Code can be modified more fluidly and IE breakpoints can even be set at a single user’s desktop when troubleshooting. Exciting and powerful tools – which require a new way of thinking.

Please fee free to download the poster I made below. Hope you find it helpful!

I’ve been learning about OData and wanted to record a quick getting started video with how to create a new WebAPI project, add OData Controller, and send HTTP CRUD operations. Below is an example using Adventure Works Departments with sample code, screenshots, and a 10 minute video introduction. Please leave a comment if you found this helpful. Thanks!