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 aa 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
Controllerclass, 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?
3 answers
solution1
5 ACCPTED 2012-03-17 11:39:36
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 ofModelinstances 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.
solution2
4 2012-03-17 13:59:10
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!
solution3
0 2012-03-17 11:20:17
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
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.