Enterprise Architecture Design for .NET Web Apps RRS feed

  • Question

  • User-735307968 posted

    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 (something similar to this), 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 3:30 PM

All replies

  • User-376018714 posted


    having a WCF layer in between your UI and DB is a overkill from my perspective. Since you have PC, tablet and mobile phone - you are on right track with the choice of WebAPI. Instead of Jquery Mobile - i would suggest you to look at Kendo UI Mobile (disclaimer - i work for Telerik. But have spent close to 12 years in Web development). Primary reason for suggesting Kendo UI for mobile also is - its nature of adaptive rendering i.e. if you use Kendo UI Mobile controls, if the web page is viewed from a browser on iOS platform - page will look like native ios ui, when the same page is viewed from android browser - page will adapt and look like native android ui. so you will provide a native look and feel for different platform with just one code base.

    you really need a Web API only when you have your data accessed by either a partner of yours or you have mobile apps which would like to consume your data. If it is just a PC browser - MVC with its controller actions, sending JSONResult are just fine. keep you action thin with all work delegated to some business service (not a web service) or BLL. Let the BLL talk to a EF context of wrap the EF context in a data manager. often we tend to complicate by adding additional stuff which you dont need. Both MVC and WebAPI provide excellent hook points to handle cross cutting concerns. you can always write action filters for your logging mechanisms.

    just my thoughts here

    Thursday, July 24, 2014 1:25 PM
  • User-1611549905 posted

    The first thing I'd say is this: keep your architecture as simple as possible. Be careful with Internet tutorials, sample apps and so on -- most of them recommend certain so-called "best practices" that add a lot of complexity and friction without conferring any benefits whatsoever.

    In particular, don't put a service between the different layers of your application. It just adds friction and slows everything down but doesn't give any value. Don't waste time trying to decouple the different layers of your application either: you almost certainly won't need to swap them out, and even if you do it's never as simple as just sliding out NHibernate and replacing it with Entity Framework or RavenDB.

    For data access, start off letting your business layer talk directly to Entity Framework. Your O/R mapper is your data access layer; it is your Repository, so adding an extra layer on top of that and calling it a Repository or DAL shouldn't be automatic. You may find that you need to add a wrapper of some form or another at some stage (for example, to help with unit tests), but if you do, make sure you keep it lightweight.

    Avoid the Anaemic Business Layer antipattern: if you find parts of your business "logic" layer don't have any logic in them, check to see that you're not letting business logic creep into your controllers or your DAL, as that makes your code harder to unit test. If, in spite of that, you still have business logic methods that don't do anything, consider bypassing your business layer altogether and going straight from your UI to your data access layer. You're more likely to find this is the case with reads rather than writes, since when you're writing data you also have to deal with things like validation and so on.

    Don't use separate assemblies for each layer. That just adds friction, slows down compilation, and causes problems when you come to upgrade your NuGet packages.

    Use test-driven development as far as possible. You will want to mock out your data access layer so you can unit test your business logic, but you should also have a suite of integration tests that hit the database as well. If you're not testing against an actual database, you're going to end up with a large surface area of functionality not covered by any form of automated tests that's not only brittle and error-prone but also business critical as well. Make sure you're running your database migrations through your automated tests too.

    Do aim for a clean separation of concerns, but at the same time make sure that your separation of concerns is appropriate. The best advice I've come across on this one comes from Kent Beck: the parts of your codebase that you're separating out should be parts that you can reason about independently. For example, it's a good idea to partition your code according to business functionality (e.g. users/logins, projects, timesheets and so on) rather than by layer -- you can't really reason about the different layers of your application independently of each other: user stories that require changes affecting several layers at once are very, very common.

    The best recommendation I can make for further reading on this subject is Oren Eini aka Ayende Rahien. He has some pretty good blog posts discussing the pitfalls of a lot of common "best practices" and discussing various alternative strategies that you can consider adopting. Just search his blog for "repository" or "design patterns" and you'll get some advice that's well worth paying attention to.

    Thursday, July 24, 2014 6:09 PM