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

Question

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!
Matt

Answer 1

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.

Answer 2

Yes, I think MVC is a different approach than "the" 3-tier architecture that I think you meant here (the architecture where you create mainly 3 projects DAL, BL, and UI). The main idea behind MVC is the separation of concerns between each of its components (Model, View and Controller). The controller is the component responsible for handling user requests, and in most cases it corporates with the "Model" component in order to display the desired view as a response to the user request. The difference between this and the traditional 3-tier architecture, is that the DAL, and the BL are grouped now and named a Model and yes you still need to create these components.
What are repositories?
Martin Fowler mentions the definition of a repository as "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects" Repositories are part of your data access layer, they don't access data by themselves, they mediate between the domain and the data mapping entities, and of course they should be placed in your Model folder/project.

Will Linq to SQL be deprecated?
NO and the same book states so, also Damien Guard ( a developer at the ADO.NET team) mentioned in one of his blog posts that Linq to SQL will be included in .NET 4.0.

How to interact with EF?
As you would with Linq to SQL. Like Linq to SQL, Entity Framework will be your mapping entities, and will reside in the Model project as well.
Hope this helps!

Answer 3

I guess you're a bit confused over these things, and they are confusing, so let's go over them slowly.

1. N-Tiered Architecture and MVC are different, but intertwined. N-Tier usually talks about separating Data Access, Business Logic and the User Interface. However, some people may argue that it is impossible to totally separate BLLs from the UI; MVC addresses that, in such a way that there is a corresponding Controller talking to your BLL, and to your View, as opposed to having your View talk directly to your BLL.

2. Yes, having repositories is one approach to having a DAL. There are many ways of doing this, and you should not limit yourself to what is discussed in the book.

3. The book only uses LINQ to SQL to demonstrate ASP.NET MVC the fastest way possible, but it is NOT the only way. Stop thinking about LINQ to SQL for a minute; ASP.NET MVC can be used whether you use an ORM like NHibernate or you use plain ADO.NET + DAL Factory or whatever -- what you'll not going to be able to use are those ASP.NET ObjectDataSources that you drag and drop with your UI.

As for Entity Framework, Brad Abrams wrote a nice guide on how to use Entity Framework with ASP.NET MVC, that should cover your last question.

HTH

Answer 4

1. Yes you still need to create data access and business logic layers yourself. Some may argue that the Controller layer IS the business logic but I personally prefer the separation between real business logic (e.g. pricing calculation) from screen business logic (e.g. event handler for the "OK" button). You will then call these from your Controller class. The controller class controls the logic for your screen and manages the translation from your data/business logic layer to the screen value.

2. the ASP.NET MVC framework puts no restriction on the "Model" layer, which means you can use whatever you want including NHibernate, LINQ to SQL or entity framework. I use LINQ to SQL because it's simple.

3. Not sure, never read that book. I just downloaded Scott Hanselman's Nerddinner project from codeplex and use that as a guide for writing ASP.NET MVC websites.