ASPHostPortal - In this article I would prefer to tell you just what the big difference in between these designs. Let’s commence with all the initial primary 1 - Model-View-Controller - it is a basic sample that applies in the several systems and every day tends to make simpler existence for programmers. If you ask computer software Architects about “How to apply this pattern”, I think you will get a pair of various answers and respectively a couple of answers. Basically, there is certainly 1 common point in these designs - is separation of User Interface (UI) from company logic, it allows do function for front-end developers not thinking about plan code. In the event you bear in mind college or university programming, it had been an enormous bunch of lines of code, composed in code behind (for instance) of .aspx documents, which is not a great practice.


MVC has a few key components: View (consumer interface), Product (company logic) and Controller (contains the logic that modifications the design because of to consumer steps, implements Use Situation). The fundamental idea of this pattern is that the controller and look at is determined by product, but the product will not depend on these two elements. It just permits you to definitely create and check a product without having realizing something concerning the sights and controllers. Preferably, the controller also will not must know about see (even though in follow this can be not often the situation) and, ideally, a single can switch controllers presentation, along with the exact same controller can be utilized for various sights (as an example, the controller might depends on person who is logged in). The consumer sees a check out, creates some motion, this motion redirects towards the controller and subscribes for adjustments from the product, controller makes particular operations with info design, and also the see will get the newest point out of the design and displays it for the consumer.
Implementation in ASP.NET looks like as follows (instance taken from MSDN [5]). Presentation - this can be a common aspx markup:
<html>
<body>
<form id="start" method="post" runat="server">
<asp:dropdownlist id="recordingSelect" runat="server" />
<asp:button runat="server" text="Submit" onclick="SubmitBtn_Click" />
<asp:datagrid id="MyDataGrid" runat="server" enableviewstate="false" />
</form>
</body>
</html>
Model – a separate class, which has methods for obtaining data (model implementations often includes Data Access Level):
public class DatabaseGateway
{
public static DataSet GetRecordings()
{
DataSet ds = ...
return ds;
}
public static DataSet GetTracks(string recordingId)
{
DataSet ds = ...
return ds;
}
}
Example of a model is not the best in this case, but it’s still not always need to have a really describe the business model in the classes, sometimes it’s enough to work with DataSets. The most interesting thing is the implementation of the controller, in fact it’s code behind of aspx page
using System;
using System.Data;
using System.Collections;
using System.Web.UI.WebControls;
public class Solution : System.Web.UI.Page
{
private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{
DataSet ds = DatabaseGateway.GetRecordings();
recordingSelect.DataSource = ds;
recordingSelect.DataTextField = "title";
recordingSelect.DataValueField = "id";
recordingSelect.DataBind();
}
}
void SubmitBtn_Click(Object sender, EventArgs e)
{
DataSet ds = DatabaseGateway.GetTracks((string)recordingSelect.SelectedItem.Value);
MyDataGrid.DataSource = ds;
MyDataGrid.DataBind();
}
#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
//
// CODEGEN: This call is required by the ASP.NET Web Form Designer.
//
InitializeComponent();
base.OnInit(e);
}
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.submit.Click += new System.EventHandler(this.SubmitBtn_Click);
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion
}
This approach will allow us to easily write tests for the model, but not for the controller (of course, all things are possible, but we need to try).
[TestFixture]
public class GatewayFixture
{
[Test]
public void Tracks1234Query()
{
DataSet ds = DatabaseGateway.GetTracks("1234");
Assertion.AssertEquals(10, ds.Tables["Track"].Rows.Count);
}
[Test]
public void Tracks2345Query()
{
DataSet ds = DatabaseGateway.GetTracks("2345");
Assertion.AssertEquals(3, ds.Tables["Track"].Rows.Count);
}
[Test]
public void Recordings()
{
DataSet ds = DatabaseGateway.GetRecordings();
Assertion.AssertEquals(4, ds.Tables["Recording"].Rows.Count);
DataTable recording = ds.Tables["Recording"];
Assertion.AssertEquals(4, recording.Rows.Count);
DataRow firstRow = recording.Rows[0];
string title = (string)firstRow["title"];
Assertion.AssertEquals("Up", title.Trim());
}
}

This sample also is made up from the 3 parts. Looking at the diagram, it really is distinct that for representation is not essential to subscribe for adjustments inside the product, the controller is renamed as Presenter, lets illustration learn about modifications. Current strategy allows you to develop an abstraction of representation. To apply this pattern, you should create interfaces of illustration. Every illustration can have interfaces with a sets of strategies and qualities which can be required for presenter, presenter initializes with correct interface, subscribes for the events of illustration and offers data when it necessary. This approach permits you to develop programs utilizing the methodology of TDD (Test-driven development). This pattern can be utilized to ASP.NET, let us take a look at the prior instance. Depart representation and product from your earlier example, and code behind of the page we'll modify just a little bit.
//Abstract View
public interface ISolutionView
{
string SelectedRecord { get; }
DataSet Recordings { set; }
DataSet Tracks { set; }
}
//Presenter
public class SolutionPresenter
{
private ISolutionView _view;
public SolutionPresenter(ISolutionView view)
{
_view = view;
}
public void ShowTracks()
{
DataSet ds = DatabaseGateway.GetTracks(_view.SelectedRecord);
_view.Tracks = ds;
}
public void Initialize()
{
DataSet ds = DatabaseGateway.GetRecordings();
_view.Recordings = ds;
}
}
//View
public class Solution : System.Web.UI.Page, ISolutionView
{
private SolutionPresenter _presenter;
private void Page_Load(object sender, System.EventArgs e)
{
if(!IsPostBack)
{
_presenter.Initialize();
}
}
override protected void OnInit(EventArgs e)
{
base.OnInit(e);
_presenter = new SolutionPresenter(this);
submit.Click += delegate { _presenter.ShowTracks(); };
}
public string SelectedRecord
{
get { return (string)recordingSelect.SelectedItem.Value; }
}
public DataSet Recordings
{
set
{
recordingSelect.DataSource = value;
recordingSelect.DataTextField = "title";
recordingSelect.DataValueField = "id";
recordingSelect.DataBind();
}
}
public DataSet Tracks
{
set
{
MyDataGrid.DataSource = value;
MyDataGrid.DataBind();
}
}
}
Right now we have logic within the presenter, and we have been able to examination SolutionPresenter with I SolutionView individually by using Mocks.
Model-View-ViewModel
Right here once again, you will find 3 elements: model, see, as well as a 3rd part - an additional model referred to as ViewModel. This pattern is ideal for technologies, where there is a two-way Binding (synchronization) of elements to the product, as in WPF. Big difference between MVVM and MVP pattern is that for MVVM SelectedRecord property, from your previous illustration, needs to be positioned inside of the ViewModel, and it should be synchronized with the required field of see. So, this is the essential thought of ??WPF. ViewModel - it is type of tremendous converter that converts information of product to the representation, it describes the fundamental homes from the check out and the logic of conversation with the design.