Sql – I need some clarification on the MVC architecture and the three-tier architecture


I've been reading the book Pro ASP NET MVC Framework and I'm getting really confused with a lot of things. I've been trying to do some research but I'm finding that with so many different approaches and concepts being thrown at me, it's just making things worse.
So I have a few questions:

  1. I know MVC is supposed to split the functionality into three main things: Model -> Controller -> View. Is the MVC a different approach than the three-tier architecture? Or am I still supposed to be thinking of creating a Data Access Layer and a Business Logic Layer in my project?

  2. What exactly are Repositories? It is what acts as my Data Access Layer? Where/How do Repositories fit into the MVC?

  3. The book talks about using LINQ to SQL to interact with the database but yet it states that LINQ to SQL will not be supported in the future and that Microsoft is dropping it for the Entity Framework. Where does the Entity Framework fit into the MVC and how do I interact with it?

Thanks in advance for your help!

Best Solution

  1. MVC is mostly a pattern for the presentation layer, and it focuses on the interaction between the view and the controller. The model can be considered to be the components of the application that are responsible for maintaining state, including persistence.

    In a simple application the model might just be an LINQ-To-SQL model. In a large enterprise application the model might contain a data access layer, business layer, and a domain layer. The ASP.NET MVC does not restrict you to how the M should be implemented.

  2. The Repository pattern is one way to implement the persistence part of the M. The ActiveRecord is another. Which pattern to choose depends on the complexity of the application, and your preferences.

    Take a look at Step 3 of the NerdDinner tutorial where they create a simple repository using Linq to SQL.

  3. Linq to SQL will not be dead. Microsoft will still improve the core and add customer requests where it makes sense but Entity Framework would be the primary focus. Take a look at this post for LINQ to SQL changes in .NET 4.0.

    The EF can be used is a similar way as LINQ to SQL, but it is also more flexible so it can be used in other ways. For example EF4 will more or less support persistence of your own POCO objects in a more Domain Driven Design.

Related Question