0 Comments

How many times did you write a code like this:

[HttpPost, ValidateAnyForgeryToken]
public async Task<IActionResult> Save(ProductModel model)
{
if(!ModelState.IsValid)
return View(model);
// invoke some business logic magic that makes money
try
{
await _dbContext.SaveChanges();
}
catch(Exception e)
{
_logger.LogError("message", e);
ModelState.AddModelError("exception", "Houston we have a problem:" + e.Message);
return View(model);
}
return RedirectToActio("Read", new { id = model.Id });
}
view raw Controller.cs hosted with ❤ by GitHub

Workflow is usually this: 

  • Try to validate user input

    • If error, return same view with error messages

  • Invoke business logic, map data to persistence model

  • Try to save data

    • If error, log to db, return view with user-readable error message (this is generic approach, true, in real app we would probably try to check what kind of error was returned and then do something specific)

  • Redirect somewhere (we are in Post-Redirect-Get loop)

To avoid of repetition of some steps there we can decorate Save actions with our special attribute!

Here's the whole filter, with all the code comments which hopefully explains how it works.

public class ValidateModelAttribute : ActionFilterAttribute
{
public override async Task OnActionExecutionAsync(ActionExecutingContext context, Action
{
var result = new ViewResult();
if (!context.ModelState.IsValid)
{
// Usually POST action looks like: IActionResult Save(MyMode model)
// if validation failed we need to forward that model back to view
// Model is in ActionArgument[0] in this case, but you may tweak
// this to your specific needs
if (context.ActionArguments.Count > 0)
{
SetViewData(context, result);
}
// This is same as
// return View(mnodel);
context.Result = result;
}
else
{
try
{
// This was all happening BEFORE actione executed.
// Lets exec the action now and catch possible exceptions!
await next.Invoke();
}
// You can catch here app specific exception!
// catch(MySpecialException e)
catch (Exception e)
{
// Uh, something went wrong:(
// Pull logger for IOC container.
// Note: I don't really like this approach, it would be much nicer to inject
// interfaces into ctor, but then we wouldn't be able to use this filter like:
// [ValidateModel] <- ctor requires interface, doesn't compile
// but like this:
// [ServiceFilter(typeof(ValidateModelAttribute))]
// so pick whatever approach you like!
var loggerFactory = context.HttpContext.RequestServices.GetService<ILoggerFactory>();
var message = e.Unwrap().Message; // Dig for inner exception message
var descriptor = context.ActionDescriptor as ControllerActionDescriptor;
var logger = loggerFactory.CreateLogger(descriptor.ControllerName);
logger.LogError($"Error while executing {descriptor.ControllerName}/{descriptor.ActionName}: {message}");
// Sets view model, and adds error to ModelState list
if (context.ActionArguments.Count > 0)
{
SetViewData(context, result);
result.ViewData.ModelState.AddModelError("", message);
}
// Again, return View(model);
context.Result = result;
}
}
}
/// <summary>
/// Sets view model from action executing context
/// </summary>
private static void SetViewData(ActionExecutingContext context, ViewResult result)
{
result.ViewData = new ViewDataDictionary(
context.HttpContext.RequestServices.GetService<IModelMetadataProvider>(),
context.ModelState);
result.ViewData.Model = context.ActionArguments.First().Value;
}
}
view raw ValidateModelAttribute.cs hosted with ❤ by GitHub
Usage is simple, just decorate your POST action with [ValidateModel] attribute, and then you can remove if(!ModelState.IsValid) checks, and also exception catch if there's any.

0 Comments

About a year a go I released nuget package for creating simple pager HTML, specifically designed to work nicely with bootstrap, since, well, the whole damn world is using that CSS framework. Until next better framework arrives ...   

It's a simple code, but to "calculate" which pages have to displayed in the pager (e.g.: 1 ... 2 3 [4] 5 6 ... 50), there's some logic behind it, so worth of packaging it into a nuget, IMHO.   

There are 3 packages released, depending how high or low somebody wants to go with abstraction   

- JA.Pagination - no dependency on any framework, API is just one Render() method with returns a string. Suitable for Nancy framework and similar ...   

- JA.Pagination.MVC5 - extension method for MVC 5 HTML helper   

- JA.Pagination.MVC6 - extension method for MVC Core (MVC 6, or now called v1 and v2)   

Usage from MVC: 

@Html.RenderPager(Model.CurrentPage, Model.TotalPages) 

But, there's one more thing worth mentioning here - usage of Decorator design pattern. If you're just learning GoF Design Patterns and looking for a real world example, this could be useful! 

Pager consists of several elements, like list item, link, content, etc. If you take a look at HTML code:

<ul class="pagination">
<li><a href="#" >&laquo;</a></li>
<li class="active"><a href="?page=1" >1</a></li>
<li><a href="?page=2" >2</a></li>
<li><a href="?page=3" >3</a></li>
<li class="disabled"><span>...</span></li>
<li><a href="?page=20" >20</a></li>
<li><a href="?page=2" >&raquo;</a></li>
</ul>
view raw pager.html hosted with ❤ by GitHub

you’ll notice how text content, for example page “2” is inside <a> tag, which is inside <li> tag, which is inside <ul> tag! So we can say text “2” is decorated with link, list item and unordered list elements. That can be modelled nicely with code:

var element = new UnorderedList(new ListItem(new Link(new Content(“page 2”))));
view raw decorator-example.cs hosted with ❤ by GitHub

each of those classes inherit from interface:

internal interface IRenderable
{
string Render();
}
view raw IRenderable.cs hosted with ❤ by GitHub

meaning, each items needs to know how to render itself! But to get “decoration” pattern working, trick is to insert another IRenderable into constructor, and that will make one IRenderable decorator of another IRenderable:

internal class LinkDecorator : IRenderable
{
private readonly IRenderable _inner;
private readonly string _url;
public LinkDecorator(IRenderable inner, string url)
{
_inner = inner;
_url = url;
}
public string Render() => $"<a href=\"{_url}\">{_inner.Render()}</a>";
}
view raw LinkDecorator.cs hosted with ❤ by GitHub

Here LinkDecorator doesn’t really care what it is decorating with <a> and </a>, it just needs to invoke that _inner.Render()!

When some top level object calls Render() method of an object, that method will call inner.Render(), that then calls its own inner.Render(), and so on, depending how many decorators we definded.

Simple, right?

Check full source code at Github.