Modern MVC Enterprise Architecture for .NET Web Apps RRS feed

  • Question

  • Hello all,

    I’m creating this post to solicit some ideas for modern enterprise architecture for a Web application that I’m about to start working on. It’s a project management application for a large enterprise. The user base will consist of internal employees and external associates. We’re planning to use VS 2013 coupled with TFS 2013 using the Agile TFS work item templates. We’ll be using SQL 2012 as the database. The target devices will be PCs, tablets and mobile phones. We’ve decided to use JQuery Mobile to handle mobile rendering. We are planning to create a separate set of views for mobile devices (Is JQuery Mobile the way to go?).

    The UI architecture that I’ve come up with so far is to use MVC5 (C#) with a Web API 2 service as a parallel to the web layer and possibly a WCF service in-between the database and Web API 2 layer, since we have other applications that will be accessing our data. Meaning the UI would contain a lot of JQuery calls to a restful API service layer for Async CRUD operations (We’re considering using Telerik’s UI component library for most of our UI data management). I would like to use the latest Entity Framework to map our database objects in the service layer. We’ll be implementing some localization features since our audience will be global. We also want to use a mocking framework for our unit tests. I’d also like to use MVCx.Unity for dependency injection across all the MVC controllers and ELMAH for exception handling. We'd also like to provide a confiugration manager to our business users to allow them to manage how some of the data is collected and rendered.

    So my questions are around the service layers and different C# patterns. If we’re exposing restful services to the UI layer (MVC5 and JQuery) via Web API 2, would it make sense to create a lower level provider layer in between the DB and Web API 2 layer using WCF as the main data access point? (We're considering having an additional service layer for our division as a general consumpion layer for logging and exceptions as well... ) The main reason for this is to be able to host the in between service on a seperate machine that can handle traffic from other sources besides our own application. As I mentioned there are other divisions that consume our data.

    What types of patterns should we consider using to handle data access? Repository? Adapter?

    What are some other patterns that might be useful to ensure that our long term strategy doesn’t get too bogged down with dependencies?

    Are there any good modern enterprise architecture resources (books, web sites etc.) that you know of that might include some diagrams and project templates or project examples?

    What are some other useful tools/frameworks that we can leverage to keep development time/cost to a minimum? 


    Thursday, October 24, 2013 7:44 PM

All replies

  • Hey there - I'm actually in the same scenario you were 2 years ago, with pretty much exactly the same questions. Can you please let me know what direction you ultimately went with, and/or some pitfalls to avoid one way or the other? 

    So far I have 2 different ways in my architecture. We started out with one central solution, called 'Data Gateway' that is a Web API 2 service layer. We use database-first with entity framework to access several different DB's to service data. So essentially there are a bunch of controllers in this one solution that use repository pattern to access the data and return it. 

    We have run into problems with this because it is such a behemoth that one little change that affects one little piece requires deployment of the entire solution.

    So instead, I have decided to separate it out into an individual Web API project Service layer for each database. That way we can now create a new database and it's project from scratch and deploy and change it independently of any other code. The only problem I now have with this way is including a 'Common' or 'Utility' that each of those projects inherits for shared code.

    So, as I said - I'm curious what you went with, and if you have any suggestions on what worked for you and what didn't.


    Jesse Milan

    Wednesday, August 12, 2015 1:30 AM
  • I'm concerned by this question. We don't know what your system does, it *should* be impossible to answer what architecture fits best. As an industry we are far too quick to pigeon-hole generic problems with types of solutions. It's kind of like saying a Tank is always the best vehicle to build when you want a vehicle to take your kids to school. I'd recommend taking some time to look at something like https://skillsmatter.com/explore?content=skillscasts&location=&q=SOA If you look at Autonomous Components then I suspect it will avoid the big ball problems Jesse has mentioned.


    Wednesday, August 12, 2015 6:39 AM