Difference between MVC controller and business logic (3 tier)

Question

I have been trying to find the different between MVC and 3-tier architecture in ASP.NET. I referred to some previous some previous questions and some pages, but could find a clear answer.
Here is a a msdn page about MVC implementation: http://msdn.microsoft.com/en-us/library/ff647462.aspx

Consider, I ahve this code:
Single page aspx UI and code as well

<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<html>
   <head>
      <title>start</title>
      <script language="c#" runat="server">
         void Page_Load(object sender, System.EventArgs e)
         {
            String selectCmd = "select * from Recording";

            SqlConnection myConnection = 
               new SqlConnection(
                  "server=(local);database=recordings;Trusted_Connection=yes");
            SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, 
               myConnection);

            DataSet ds = new DataSet();
            myCommand.Fill(ds, "Recording");

            recordingSelect.DataSource = ds;
            recordingSelect.DataTextField = "title";
            recordingSelect.DataValueField = "id";
            recordingSelect.DataBind();
         }
       </script>
   </head>
   <body>
         <asp:dropdownlist id="recordingSelect" runat="server" />
         <asp:button runat="server" text="Submit" OnClick="SubmitBtn_Click" />
      </form>
   </body>
</html>

Now, consider I have different files for
---- View and Code-behind spearated ----
.aspx

<%@ Page language="c#" Codebehind="Solution.aspx.cs" 
   AutoEventWireup="false" Inherits="Solution" %>
<html>
         <asp:dropdownlist id="recordingSelect" runat="server" />
      </form>
   </body>
</html>

.aspx.cs

using System;
using System.Data;
using System.Data.SqlClient;
public class Solution : System.Web.UI.Page
{
   private void Page_Load(object sender, System.EventArgs e)
   {
      if(!IsPostBack)
      {
         String selectCmd = "select * from Recording";
         SqlConnection myConnection = 
            new SqlConnection(
               "server=(local);database=recordings;Trusted_Connection=yes");
         SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);
         DataSet ds = new DataSet();
         myCommand.Fill(ds, "Recording");
         recordingSelect.DataSource = ds;
         recordingSelect.DataTextField = "title";
         recordingSelect.DataValueField = "id";
         recordingSelect.DataBind();
      }
   }

Seeing the above msdn page link for the Controller class, I am not able to discern the difference between the business logic (that would have been similar for a middle tier in a 3 tier architecture) and the controller.
Is 3-tier and MVC completely different thing? Are the ASP.NET application in Visual Studio already separated file as in MVC form? If these are not different, which one is the preferred style?
What's the MVC framework about then if the .aspx and .aspx.cs are already spearated?

ntziolis · Accepted Answer · 2012-03-17T11:54:15.063

I actually strugled with this a while myslef, there are different philosophies on how to implement it correctly, so this is how I understand it in my own words how I understand the relation between the different things involved (Models/Views/Controllers/Business Logic):

Views
Have all the Html / jQuery code, they use the data in form of Model instances that come from the controller
Models
The classes that hold the information your View needs to render (List of products etc)
Controllers
- They take incoming requests
- Make the necessary preparations (parameter extraction etc.) to call your actual business logic code.
- Then the call into the business logic code and retrieve the result
- Afterwards they take the result and transforms it into a Model that the UI understands
Business logic
This is your actual business logic code, calling the db etc. I my eyes this is totally separate from the entire MVC thing, in fact it should not even know it is executed from a MVC web application. Usually we put this in a different assembly (class library) to make sure there is no dependency to MVC code at all.
This makes it very simple to unit test just the business logic, since there are no dependencies to MVC.

I have seen other approaches where the business logic is actually put into the controllers, but in my eyes that defeats the purpose. We are not building MVC applications to have a nice structure, but also to be able to perform unit test better.

Getting back to your question, how does it all relate to ASP.NET 3-tier architecture.
One could say that basically the entire MVC web application is nothing more the Presentation layer (+ wireing up the Presentation layer with the Busines layer).

The other layers stay separate and independent from the presentation layer, as they should have before.

This is entirely true. I would also say the Views contain the presentation logic while the Controllers contain the application logic in the presentation tier. Furthermore, the Model is generally part of the business layer. — Balazs Tihanyi, Mar 17 '12 at 12:28
@BalazsTihanyi Actually we go as far as not making the business layer aware of the models used by the views, the business layer is using a different set of 'models' and the results get mapped to the models within the controllers (automapper i'm looking at you) — ntziolis, Mar 17 '12 at 12:47

David · Answer 2 · 2013-01-30T23:19:12.033

MVC and 3-tier are completely different things.
I see a lot of people confuse the two because both got 3 parts.

MVC is a UI pattern:
View: contains html and js only (in case of a web project)
Controller: is a kind of a mediator between the UI (= the view) and the back-end (= the model)
Model: this is where your domain objects live, as well as the business and data-access logic

3-tier concerns the whole of you application:
UI: contains the html/js as well as the code behind of the pages.
There is absolutely no logic here, other than UI code and calling the business layer.
Business layer: this is where you put things like calculations, conditions, validation, ..
So the actual behaviour of your application. There is no data access code here.
Data access: here where you talk to the database and return the data to the business layer.
Nothing else, the business layer should know what to do with it.

So if you combine the two, you'll get:
UI: views and controllers
Business layer: part of the model
Data access: part of the model
Domain object: you'll want to put the objects you're working with (product, order, ..) in a separate layer.
This is also a part of the model.

Shoot if you got questions!

Rich · Answer 3 · 2012-03-17T11:34:14.203

0

See here for a good comparison between "layers" and "tiers" in software architecture/design

The MVC pattern is all about separation of concerns, and the fact that your presentation layer (the view) and the business logic should be separated. Using code behind makes it easy to muddy the waters. You'll find that the new ASP.NET view engine (Razor) doesn't even have code behind files.

The main difference, which will start to matter more when you want to test the logic in your controller automatically, is that a controller is just a plain old class, but your codebehind inherits from System.Web.UI.Page and thus is strongly tied to the innards of ASP.net.

Also, read http://ardalis.com/Codebehind-Files-in-ASP.NET-MVC-are-Evil and https://msmvps.com/blogs/luisabreu/archive/2008/09/19/codebehind-files-in-asp-net-mvc-are-not-evil.aspx

edited Mar 17 '12 at 11:34

answered Mar 17 '12 at 11:20

Rich

3,640
3
20
24

I read this earlier. Seems to me that the only difference is that the M & V can interact with Controller directly (in MVC), which on the other hand in a 3-tier architecture, the communication has to be done through business logic. Looks like two different approaches, with a fine perceptible difference. Is there an advantage of choosing between MVC or 3 tier? – user1240679 Mar 17 '12 at 11:31
I would say that 3 tier and MVC are very different concepts (as the MVC pattern is used now), 3 tier refers more to having your data access logically (and often physically) separated from your business logic, so in todays terms MVC becomes the first two tiers of your application, but you still have a data access "tier" sat behind that – Rich Mar 17 '12 at 11:40
This question also addresses MVC vs 3-tier http://stackoverflow.com/questions/1025430/i-need-some-clarification-on-the-mvc-architecture-and-the-three-tier-architectur – Rich Mar 17 '12 at 11:41
@Rich I think the entire MVC application should be seen as the Presentation layer (+ wiring up the controllers to the business layer). The business layer should be somewhere entirely separate, best to put it in a separate assembly. If you do it right it does not even know it is run in a web application, nor knows anything about the MVC assemblies – ntziolis Mar 17 '12 at 12:00
@ntziolis there's no one right answer, but I would agree with http://stackoverflow.com/questions/235233/asp-net-mvc-should-business-logic-exist-in-controllers and believe at least some of the business logic belongs in the model – Rich Mar 17 '12 at 12:00
@Rich I agree, there is no right answer. Personally me and my team treat models as pure data passing classes between views and controllers. And controllers are treaded as routers to the business logic, so the business logic is outside of the mvc applications and easily unit testable, so I don't really like the ideas of fat models – ntziolis Mar 17 '12 at 12:07

Difference between MVC controller and business logic (3 tier)

3 Answers3