Let me say smth. ;)

Classic book example for the simple MVC application doesn't work if you want to display it as provider hosted app in SharePoint! By classic, I mean situation where you have 2 Controller's actions with the same name, but for different HttpMethods: Get and Post. You use "Get" to display information to a user and "Post" to retrieve updated information back from the user. For example, EditProduct "Get" action will return some product information, and EditProduct "Post" action will receive updated model from the view and presumably save it to the DB. It gets tricky with SharePoint - it always sends HttpPost to your Controller, so EditProduct "Post" action gets hit. The only workaround I found so far (I don't have that extensive experience with MVC as I have with WebForms) is to simply rename EditProduct "Post" action to SaveProduct and explicitly set Form action to "SaveProduct".

So what’s inside this well-advertised approach? Actually, in terms of web development nothing new. It’s a web widget that: • Can be any of your web applications hosted in Azure, IIS, Apache etc. • Can be the same as above but hosted within an iframe embedded to a SharePoint page (App Part) • Can be an html code block with JavaScript and CSS being executed in user browser In addition, Microsoft renamed some of its existing functional pieces like list, libraries, application pages etc. to Apps which obviously confuse developers at start. I think the most useful change for developers is a new extended REST/OData service and Client-Side Object Model which enable external code in the Apps to interact directly with SharePoint artifacts. Another beneficial change is that SharePoint 2013 supports OAuth authentication which means that an App can interact with SharePoint on behalf of users once they have logged in and authorized the App. Useful links: Start building apps for Office an...