ASP.NET MVC3 and Entity Framework Code first architecture RRS feed

  • Question

  • Some problems I encountered made me think again about layers, repository, dependency injection and architectural stuff like this.

    My architecture now looks like this:
    I am using EF code first, so I just made POCO classes, and context. That creates db and model.
    Level higher are business layer classes (Providers). I am using different provider for each domain... like MemberProvider, RoleProvider, TaskProvider etc. and I am making new instance of my DbContext in each of these providers.
    Then I instantiate these providers in my controllers, get data and send them to Views.

    My initial architecture included repository, which I got rid of because I was told that it just adds complexity, so why I don't just use EF only. I wanted to did that.. working with EF directly from controllers, but I have to write tests and it was a bit complicate with real database. I had to fake - mock data somehow. So I made an interface for each provider and made fake providers with hardcoded data in lists. And with this I got back to something, where I am not sure how to proceed correctly.

    These things starts to be overcomplicated too quickly... many approaches and "pattterns"... it creates just too much noise and useless code.

    Is there any SIMPLE and testable architecture for creating and ASP.NET MVC3 application with Entity Framework?

    Sunday, April 10, 2011 3:24 AM

All replies

  • My first piece of advice would be to design your database first rather than code first. If you don't have people who understand how databases work then you should take a step back and think about where your data is going when it runs live.

    MVC is fiddly.  Webforms is quicker and easier IMO. 

    You can test without automated testing.  It just takes more time if you're making a lot of changes.  Personally, when doing webforms I test as I go anyhow.  So the end result is tested.  It's just that someone else has to repeat the tests manually if you need to repeat them.  Having someone else test your work without following exactly the same process is a good thing IMO.

    What else. Mocking.

    You need mocking layers if you're going to go with TDD because it takes too long to run your tests otherwise. If you could settle for batch testing overnight instead then you can have a test database.  Also, it's pretty much impossible to write code without your objects and methods being dependent on others.  So you need to  mock them to isolate for your tests.


    Sunday, April 10, 2011 7:57 PM
  • Thanks for reply Andy.

    I am doing code first, because I am trying to work in variation of "XP" way. I don't know how will the final db look and it's easier to rewrite few classes and one seed method, than changing structure and content of database.

    Also the use of MVC part (which serves as a client in this case) isn't a problem here imo. The problem was about lower levels of architecture... business and data access. But from what I have read so far, I believe that my current solution fits best to my scenario.

    I will have to learn more about mocking. I believe that I am doing it now, but I am doing it manually (writing own classes against defined interfaces with static data).

    Monday, April 11, 2011 8:01 AM
  • Creating the database first forces you to think through your entities.

    Thats a GOOD thing.

    Because if you don't have a clue what your database is going to look like then you're wasting your time writing code IMO.

    Monday, April 11, 2011 8:20 AM
  • I know what entities will I need (most of them), but I don't know exactly what attributes will they have. Ie. I know, that my Task entity is going to have some title, description, start date, end date and id of user which is responsible for it. But later on I will need to add some more attributes.
    Monday, April 11, 2011 8:37 AM
  • I wish I was still that optimistic mate.

    Personally, I'd hold off on coding until I  had a better understanding of the requirements.  It's much more time consuming to build something half understood and then fix it up than understand the requirements and design to meet them before building anything.

    Like building:

    Plan > foundations > walls > roof > first fix > decorate.

    Trying to build the roof without a plan doesn't work so well. 

    The exceptions being very small apps or those built using very simple layers.

    In Access, for example, you can lash something together pretty quick as a single user app.  Makes it pretty good for protptyping imo.

    Monday, April 11, 2011 10:33 AM
  • I would certainly agree you need to consider the requirements. However, I would not agree that you need to do the database first or that web forms is a good choice. Sometimes they are good choices, other times not. You'll only know that once get have a holistic view of the requirements. That's not to say you need to delve into the requirements, no just enough so you've got a picture of where you are going. E.g. if you system is for 10 users with a concurrency of next to nothing then fine; create a database, use Dynamic Data Services and you've finished. If you have a lot of load, true concurrency problems then a SOA style is needed where you probably would NOT create the database first. Most requirements pitch up somewhere inbetween, but the architecture must reflect the problem it's trying to solve.
    Tuesday, April 12, 2011 8:24 AM
  • I'm going to strongy disagree with Andy.

    First off, MVC is the first .net framework created so we can develop web applications the way the web work. 

    Secondly "Creating the database first forces you to think through your entities."  Your application objects define what your application can do.  Just like the UI is just presentation, database tables are just (again *JUST*)  storage.

    petrdam:  If my advice counts for anything:

    Start your application by defining your application objects. Create service contracts for how your application will be using this entities (actuall implementation not important at this stage)

    Model your database without thinking too much about what your domain objects look like.  While the bigger the mismatch, the more complicated mapping them becomes, it does not matter.  *Should* not matter.  They serve complete different purposes.

    Create implementations ofr your service contracts that use whatever you like (, Enity Framework, nHibernate...whatever) that map your domain objects and the database tables.

    UI does not matter what you use...but since it will work against a set of contracts (interfaces) you got yourself a loosely coupled start for a well maintainable application.

    Just my 20 bucks.

    Thursday, May 12, 2011 9:33 AM
  • You have posed several question and I will try and answer them.

    * Should you be using EF?  Is it too complicated and preventing testing.

    I did some investigation into the use of EF to asses its suitability for the projects I am architect on.  My conclusion was that it was not yet ready for enterprise development and deployment due to it's lack of "good" strored procedure support.  For scaleable secure apps database access should be via strongly typed stored procedures.  This may have changed with subsequent versions.

    I also concluded that like a lot of object relational mapping frameworks down the years - it tends to make your object design and your database design similar.  These should be different, the object design essentially being a de-normalised view of your data required by your application and your database schema being "normalised till it hurts, denormalised until it works".

    That said, for simple applications with little business logic and without scalability or security constraints - EF will do the job.

    You can reed about my investigations of entity framework and MVC on my blog

    * How to you test it

    If it's a UI my recomendation would be to build UI tests using selenium.  This will then completely throughtest your app - inlcuding the "real" database. (


    * Should You use MVC?

    For someone used to standard web forms - MVC can be a bit of a pain.  Havig sid that it forces you to decouple your business code and UI code (which you should be doing anyway) and avoids the pitfalls of viewstate.

    The other consideration is that ASP.NET forms have been around much longer and so are better supported (more documention and samples) and are in less of a state of flux (version changes).

    So - if your confident with MVC, use it.  If you want to develop a bit more quickly then use standard forms.

    Of course - you could also consider using purish html and javascript (jquery/ajax) to call web services/REST service.  This will also enforce separation of business logic and mean you have a set of tested web services to interface to your app.

    However, this is not for the feint hearted as the javascript is not quick to test and develop.  An alternate is to expose your business layer as web services and call those from your web layer - again gives you a set of tested web services.

    Points raised by others:

    * Schema design or object design first.

    IMHO - do the one your most comfertable with first and then translate to other using normalisation or denormalisation.

    * Do I need to do design in XP?

    Yes - XP is about delivering a bit at a time but if you have not got a fundamentally good design then the extra "bit at a time" could have huge implications on your existing code/architecture.

    Say your using names and addresses in 1 table and then you find out at iteration 4 that people can have two addresses = big change.

    Best to at least have a basic schema, process and object design which will cover all your major use cases before you start cutting the code.

    Good luck


    Friday, May 13, 2011 12:57 PM
  • To make an architectural decisions, one should know few requirements. There are few questions

    1. What were the reasons for choosing Asp.NET MVC, entiry framework etc?

    2. Have domain model is developed through?

    3.Is this system going to be customized in terms of database scheme?

    If domain analysis is done, database design could be worked out (if it is not be be decided by users). Code first or database first are pure convinience decisions.

    You have mentioned about XP- extreme programming, right? If its that, XP is characterised by enough design upfront, pair proogramming, user stories, test suites, CRC cards etc. Architecture and design activity is part of design in XP and XP way doesn't come in having better design.

    Criterias for choosing architecure and design pattenrs include

    1. Functional requirements

    2.Quality attributes like Performance, scalability etc

    3. Design principles

    EF, ASP.NET MVC are implementation ways (technology choices) for architeture and design designs.

    Refer following article for simple sample

    Hope this helps.

    • Edited by Vishvvas Tuesday, May 31, 2011 10:26 AM Addition
    • Proposed as answer by Vishvvas Wednesday, June 1, 2011 6:32 AM
    Tuesday, May 31, 2011 8:37 AM