Architecture for ASPNET MVC Web Application

Question

I'm planning to realize a ASPNET app to learn the MVC stuff and i'm thinking to use the following architecture: ASPNET MVC 4 WebApplication that uses knockout.js in the frontend and consumes ASPNET WebApi Controller methods on the server side for setting/getting SqlServer database data through Entity Framework. In this way i would be able to invoke ASPNET WebApi URLs also from a (future) mobile app. Does this architecture makes sense?

Answer 1

A brief history of Asp.Net MVC framework

ASP.Net MVC is a new Framework built on the top of Microsoft .Net Framework to develop web application. This framework implements the MVC pattern which helps to provides separation of code and also provide better support for test-driven development (TDD). Asp.Net MVC is a lightweight and highly testable open source framework for building highly scalable and well designed web applications. Here is the list of released version history of ASP.NET MVC Framework with theirs features.

Asp.Net MVC1

Released on Mar 13, 2009

Runs on .Net 3.5 and with Visual Studio 2008 & Visual Studio 2008 SP1
MVC Pattern architecture with WebForm Engine
Html Helpers
Ajax helpers
Routing
Unit Testing

Asp.Net MVC2

Released on Mar 10, 2010

Runs on .Net 3.5, 4.0 and with Visual Studio 2008 & 2010
Strongly typed HTML helpers means lambda expression based Html Helpers
Templated Helpers
Support for Data Annotations Attribute
Client-side validation
UI helpers with automatic scaffolding & customizable templates
Attribute-based model validation on both client and server
Overriding the HTTP Method Verb including GET, PUT, POST, and DELETE
Areas for partitioning a large applications into modules
Asynchronous controllers

Asp.Net MVC3

Released on Jan 13, 2011

Runs on .Net 4.0 and with Visual Studio 2010
The Razor view engine
Improved Support for Data Annotations
Remote Validation
Compare Attribute
Sessionless Controller
Child Action Output Caching
Dependency Resolver
Entity Framework Code First support
Partial-page output caching
ViewBag dynamic property for passing data from controller to view
Global Action Filters
Better JavaScript support with unobtrusive JavaScript, jQuery Validation, and JSON binding
Use of NuGet to deliver software and manage dependencies throughout the platform
Good Intellisense support for Razor into Visual Studio

Asp.Net MVC4

Released on Aug 15, 2012

Runs on .Net 4.0, 4.5 and with Visual Studio 2010SP1 & Visual Studio 2012
ASP.NET Web API
Enhancements to default project templates
Mobile project template using jQuery Mobile
Display Modes
Task support for Asynchronous Controllers
Bundling and minification
Support for the Windows Azure SDK

Asp.Net MVC5

Released on 17 October 2013

Runs on .Net 4.5, 4.5.1 and with Visual Studio 2013
One Asp.Net
Asp.Net Identity
ASP.NET Scaffolding
Authentication filters - run prior to authorization filters in the ASP.NET MVC pipeline
Bootstrap in the MVC template
ASP.NET Web API2

Credit To: Mr. Shailendra Chauhan

Answer 2

Be warned that trying to use the same Web API to drive a javascript client and a mobile client is a very challenging proposal. It is common when building a Web API for a javascript client that there is lots of "out of band" coupling between the client and server. You can tell this whenever you see see an api that delivers application/json and the client has to know in advance what the contents of that json document will be.

This approach works fine for a Web site where you can update the Web API and the Web site almost simultaneously. However, it is not so easy to do with a mobile application that requires having updates submitted to an app store for approval before it can be deployed.

A common symptom of this problem is where developers are forced to create new versions of the API so that existing mobile clients can continue to work while new mobile clients are rolled out against a completely new API. Regularly versioning an API is not a huge issue while you are the only consumer of your API. When third party API consumers get involved, it starts to get nasty.

Personally, unless you see a major strategic advantage to building a SPA style application, then I wouldn't bother creating an API to drive your website.

I would recommend that you have a clear understanding why you want to drive your web site with an API rather than just following the current "fashion".