Reputation: 1585
I am at the very first step of MVC.
In my first example I have a Model like so:
public class GuestResponse
{
[Required(ErrorMessage = "Please enter your name")]
public string Name { get; set; }
[Required(ErrorMessage = "Please enter your email")]
[RegularExpression(".+\\@.+\\..+", ErrorMessage = "Please enter a valid email address")]
public string Email { get; set; }
public string Phone { get; set; }
[Required(ErrorMessage = "Please specify whether you'll attend")]
public bool? WillAttend { get; set; }
}
the Controller:
public class HomeController : Controller
{
public ViewResult Index()
{
ViewData["greeting"] = (DateTime.Now.Hour < 12 ? "Good morning" : "Good afternoon");
return View();
}
[HttpGet]
public ViewResult RsvpForm()
{
return this.View();
}
[HttpPost]
public ViewResult RsvpForm(GuestResponse guestResp)
{
if (ModelState.IsValid)
{
return this.View("Thanks", guestResp);
}
else
{
return this.View();
}
}
}
and a View:
<body>
<div>
<h1>
Thank you,
<%: Model.Name %>.</h1>
<p>
<% if (Model.WillAttend == true)
{ %>
It's great that you're coming. The drinks are already in
the fridge!
<% }
else
{ %>
Sorry to hear you can't make it, but thanks for letting
us know.
<% } %>
</p>
</div>
What seems strange to me, is that the View is thightly coupled with the Model: it uses code like Model.WillAttend
ecc... So what happen if in a future time the Model changes? I should have to change all the snippets inside this particular View (but possibly also in many other views...)
Is this tight-coupling or am I missing the point here?
EDIT
In the book the Author points out that this useful mechanism is
Model Binding
Given that the method [public ViewResult RsvpForm(GuestResponse guestResp)] is being invoked via an HTTP request, and that GuestResponse is a .NET type that is totally unknown to HTTP, how can an HTTP request possibly supply a GuestResponse instance? The answer is model binding, an extremely useful feature of ASP.NET MVC whereby incoming data is automatically parsed and used to populate action method parameters by matching incoming key/value pairs with the names of properties on the desired .NET type. This powerful, customizable mechanism eliminates much of the humdrum plumbing associated with handling HTTP requests, letting you work primarily in terms of strongly typed .NET objects rather than low-level fiddling with Request.Form[] and Request.QueryString[] dictionaries, as is often necessary in Web Forms. Because the input controls defined in RsvpForm.aspx render with names corresponding to the names of properties on GuestResponse, the framework will supply to your action method a GuestResponse instance already fully populated with whatever data the user entered into the form.
My two cents: but so, this mechanism give you the advantage of strongly typed classes inside the View (which, however, is really useful thanks to Visual Studio Intellisense feature, otherwise in my opinion also the Request.Form[] syntax would fit the same). On the other hand, you are tightly coupling the View with the Model, so that every tiny change to the Model will result in a cascade of changes on linked Views.
Upvotes: 2
Views: 1290
Reputation: 82096
Is this tight coupling or am I missing the point here
Yes it is tight coupling and the point you maybe missing is - this isn't the M
in MVC, this is a different type of model called a view model and it's supposed to be tailored for a specific view so it makes sense that it's coupled.
It's generally known as MVVM, a derivation of MVC which introduces the notion of view models to de-couple your actual model from the view.
Upvotes: 2