Modern Web Application Layered High Level Architecture with SPA, MVC, Web API, EF, Kendo UI, OData

This will be part one of a six part series of blog posts.

  1. Modern Web Application Layered High Level Architecture with SPA, MVC, Web API, EF, Kendo UI, OData
  2. Generically Implementing the Unit of Work & Repository Pattern with Entity Framework in MVC & Simplifying Entity Graphs
  3. MVC 4, Kendo UI, SPA with Layout, View, Router & MVVM
  4. MVC 4, Web API, OData, EF, Kendo UI, Grid, Datasource (CRUD) with MVVM
  5. MVC 4, Web API, OData, EF, Kendo UI, Binding a Form to Datasource (CRUD) with MVVM
  6. Upgrading to Async with Entity Framework, MVC, OData AsyncEntitySetController, Kendo UI, Glimpse & Generic Unit of Work Repository Framework v2.0

Update: 07/22/2013 – Added blog series on actual implementation steps, for this architecture with patterns towards the end of this blog post.

Search and searched and seems difficult to locate any comprehensive top down, full stack architecture or high level design diagrams for modern (SPA) web apps. It’s probably important you have at least a high level picture what this architecture looks like now that there is quite a bit more design work involved on the client side especially with more and more implementations are around SPA and patterns like MVVM; so hence this post. Obviously there is no such thing as one size fits all especially when it comes to architecture, so feel free to omit or add to the architecture based on your specific needs.

Modern Web Application Logical and Physical Architecture High Level Design with SPA

Client Layer (HTML5 Browser)
Model View ViewModel (MVVM) is a design pattern which helps developers separate the Model (the data) from the View (the UI). The View-Model part of MVVM is responsible for exposing the data objects from the Model in such a way that those objects are easily consumed in the View. Kendo MVVM is an implementation of the MVVM pattern which seamlessly integrates with the rest of the Kendo framework (widgets and DataSource).

Web Layer (Server)
Almost the entire ASP.NET MVC Web Layer can leverage the DI & IoC Pattern, you can read up on what the benefits are and how to do this download both a sample MVC app that uses MEF or Unity 3 from one of my previous post.

  • Presentation Layer
    For modern MVC web applications, the presentation layer (server-side) consists of a Controllers who’s only tasks are to render an HTML page, css, Javascript, HTML templates, images, etc. Very little server-side code, if any, is responsible for any UI rendering responsibilities. Once the page is rendered in the browser client-side components (the browser or user agent that executes scripts and displays the HTML). With client-side techniques such as AJAX and with rich client-side frameworks such as Kendo UI Web, it is possible to execute logic on the client, for nice fluid user experiences. Implementing a SPA, can greatly increase the user experience by, reducing or eliminating post backs and refreshes.

  • Business Layer
    When designing the business layer for your Web application, consider how to implement the business logic and long-running workflows. Using a separate business layer that implements the business logic and workflows can improve the maintainability and testability of your application, and allow you to centralize and reuse common business logic functions.

  • Data Layer
    Consider designing a data layer for your Web application that abstracts the logic necessary to access the database. This can be achieved with implementing the Repository pattern, the Repository pattern is often implemented with the Unit of Work pattern. Entity Framework already implements the Unit of Work Pattern with the DbContext, however you should always work an abstraction of this, you can read up on one of previous post on how to do this. Using a separate data layer makes the application easier to configure and maintain, and hides the details of the database from other layers of the application.

    Your business entities, usually shared between the layers of your application e.g. Business and Data Layer should be POCO entities. Entity Framework enables you to use custom data classes together with your data model without making any modifications to the data classes themselves. This means that you can use “plain-old” CLR objects (POCO), such as existing domain objects, with your data model. These POCO data classes (also known as persistence-ignorant objects), which are mapped to entities that are defined in a data model, support most of the same query, insert, update, and delete behaviors as entity types that are generated by the Entity Data Model tools.

Services Layer
Consider designing a separate service layer if you plan to deploy your business layer on a remote tier, or if you plan to expose your business logic using a Web service. Design the services to achieve maximum reusability by not assuming the specific details of clients that will use them, and avoid changes over time that might break the service interface for existing clients. Instead, implement versions of the interface to allow clients to connect to the appropriate version.

Download PNG Version
Download PDF Version

I’ve posted a three part blog series, that covers the actual implementation of most of this architecture and patterns used:

Part 1 – MVC 4, Kendo UI, SPA with Layout, View, Router & MVVM
Part 2 – MVC 4, Web API, OData, EF, Kendo UI, Grid, Datasource (CRUD) with MVVM
Part 3 – MVC 4, Web API, OData, EF, Kendo UI, Binding a Form to Datasource (CRUD) with MVVM

Happy Architecting…!

10 thoughts on “Modern Web Application Layered High Level Architecture with SPA, MVC, Web API, EF, Kendo UI, OData

  1. How to create new record? I am implementing full of your demo in my project but I am unable to add new record to database from kendo UI. Please help.


  2. Within the last 6 months or so, the man has lost his masculine figure.
    The inability to hold an erection can also be related to
    heart disease, so men need to talk to their doctor. These include mood swings, hot
    flashes, lack of libido, increased body and facial hair and even
    the lowering of the voice.


  3. Pingback: Developing an Android App « The Cerebral Kitchen

  4. Hey Le,
    I’ve been an ardent reader of all your posts. Brilliant stuff!
    However, I’ve had 2 questions which have been niggling me for a while now and I haven’t found a satisfactory response for them.
    1] What’s the advantage of using the EF, if I have a db. where all the stored procedures are already defined?
    2] As far as the repository pattern goes, everything I have read/seen so far has 1 repository for 1 entity .i.e. a 1:1 relationship. In this case, what happens if the business layer needs results that span across entities – inner/left/outer join. In which repository would this API live?


  5. Hi Le,

    We did actually build a few large enterprise applications based on successfully at first and painful at last 🙂
    The problems arises at implementation phase when we wanted to apply team development. But it was most painful when the applications enters the maintenance phase.
    Even a minor change like adding a database column did force us to release/update most of the assemblies. So after doing this architecture in 4 large enterprise applications we finally decided to rethink the whole idea for architecture. In very short we came to these conclusions:
    1- The large enterprise applications have more than one UI. So the architecture should support for example:
    multiple different ASP.NET MVC websites, HTML5 client apps, Windows Consoles, Windows Services,…
    So it’s better to leave this layer as open as possible. Because no body could possibly know how an application should look like over a while.

    2- When possible try to avoid mixed database architecture like
    3- Go modular(like plugins). Try to build the modules which take care of every thing above database and under presentation layers vertically. So a module/plugin should be build to take care of webapi/odata/WCF/WF,…

    4- Use IoC like Unity or autofac instead of MEF. The TDD would be much easier.

    5- Try to find the best place to abstract. Abstract the product and not the product details like size, color.

    6- Use Enterprise library of libraries like that for AOP.

    We did an experiment with other architecture with assemblies Core, Framework and different modules/plugins and it went very well. We looked at architecture of Orchard CMS (very much like Apache Webserver) and NopCommerce and learned a few things. We were able to modify/upgrade the modules with minimal impact en very reliable 🙂



    • Thanks for taking the time out and illustrating some of your lessons learned. I’ve also have had some common shared experiences with architectures that were brittle. 🙂


  6. Hi Long Le,
    I’m familiar with . There is also an extensive document to make the idea’s behind it more clear. In my opinion the above diagram is very close to what Cesar and his colleagues at Microsoft Spain tried to show. So both are good and none could be perfect. Because there is no ‘one size fits all’ for all scenario’s. The more challenging part would be to build an example to show these diagrams are more than just a diagram. Especially, showing a real-world modular software which composes the modules at run time.

    By the way, I really like your blog and planning to read all of your posts.



  7. Pingback: Modern Web Application Layered High Level Architecture with SPA, MVC, Web API, EF, Kendo UI - HTML vNext - HTML 5 and Beyond | HTML vNext - HTML 5 and Beyond

Comments are closed.