La convención ya está disponible sin saltar demasiados aros. El truco consiste en cablear los valores TextBox basados en el modelo que pasas a la vista.
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult CreatePost()
{
return View();
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult CreatePost(FormCollection formCollection)
{
try
{
// do your logic here
// maybe u want to stop and return the form
return View(formCollection);
}
catch
{
// this will pass the collection back to the ViewEngine
return View(formCollection);
}
}
Lo que sucede a continuación es el ViewEngine toma la FormCollection y coincide con las llaves dentro de la colección con los nombres de ID/valor que tiene en su punto de vista, el uso de los ayudantes HTML. Por ejemplo:
<div id="content">
<% using (Html.BeginForm()) { %>
Enter the Post Title: <%= Html.TextBox("Title", Model["Title"], 50) %><br />
Enter the Post Body: <%= Html.TextArea("Body", Model["Body"]) %><br />
<%= Html.SubmitButton() %>
<% } %>
</div>
¿Observe que el cuadro de texto y el área de texto tienen los ID de Título y Cuerpo? Ahora, observe cómo estoy configurando los valores del objeto Modelo de Vista? Ya que aprobó en un FormCollection (y debe configurar la vista para que esté fuertemente tipeado con un FormCollection), ahora puede acceder a él. O bien, sin un fuerte tipado, simplemente puede usar ViewData ["Title"] (creo).
POOF Tu mágico ViewState.Este concepto se llama convención sobre configuración.
Ahora, el código anterior está en su forma más simple y más pura con FormCollection. Las cosas se ponen interesantes cuando comienza a usar ViewModels, en lugar de FormCollection. Puede comenzar a agregar su propia validación de sus Models/ViewModels y hacer que el controlador active automáticamente los errores de validación personalizados. Esa es una respuesta para otro día sin embargo.
Sugeriría utilizar un PostFormViewModel en lugar del objeto Post, pero para cada uno. De cualquier manera, al requerir un objeto en el método de acción, ahora obtiene un método IsValid() al que puede llamar.
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult CreatePost(Post post)
{
// errors should already be in the collection here
if (false == ModelState.IsValid())
return View(post);
try
{
// do your logic here
// maybe u want to stop and return the form
return View(post);
}
catch
{
// this will pass the collection back to the ViewEngine
return View(post);
}
}
Y su punto de vista inflexible de tipos tendría que ser ajustado:
<div id="content">
<% using (Html.BeginForm()) { %>
Enter the Post Title: <%= Html.TextBox("Title", Model.Title, 50) %><br />
Enter the Post Body: <%= Html.TextArea("Body", Model.Body) %><br />
<%= Html.SubmitButton() %>
<% } %>
</div>
que puede tomar un paso más allá y mostrar los errores, así como en la vista, directamente desde el ModelState que configure en el controlador.
<div id="content">
<%= Html.ValidationSummary() %>
<% using (Html.BeginForm()) { %>
Enter the Post Title:
<%= Html.TextBox("Title", Model.Title, 50) %>
<%= Html.ValidationMessage("Title") %><br />
Enter the Post Body:
<%= Html.TextArea("Body", Model.Body) %>
<%= Html.ValidationMessage("Body") %><br />
<%= Html.SubmitButton() %>
<% } %>
</div>
Lo que es interesante con este enfoque es que se dará cuenta de que no estoy estableciendo el resumen de validación, ni los mensajes de validación individuales en la vista. Me gusta practicar conceptos DDD, lo que significa que mis mensajes de validación (y resúmenes) están controlados en mi dominio y se pasan en forma de colección. Luego, recorro la colección (si existe algún error) y la agrego a la colección ModelState.AddErrors actual. El resto es automático cuando devuelve View (post).
Muchos de los congresos se agotaron. Algunos libros le recomiendo que la cobertura de estos patrones en mucho más detalle son:
Y en ese orden la primera abarca los frutos secos crudos y los pernos de todo el marco MVC . Este último cubre técnicas avanzadas fuera de la versión oficial de Microsoft, con varias herramientas externas para facilitarle la vida (Castle Windsor, Moq, etc.).
Te das cuenta de que ViewState solo usa entradas ocultas, ¿no? HTTP es sin estado, y ASP.NET MVC lo abarca en lugar de abstraerlo. –
@mgroves - Sí, me doy cuenta de que es apátrida. Es por eso que mencioné la simulación de ViewState usando entradas ocultas. – nickytonline
Solo estoy diciendo que no estarías 'simulando' ViewState, harías básicamente lo mismo. Por supuesto, con el patrón MVC, (idealmente) necesitarías hacer mucho menos. –