How many times did you write a code like this:

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.

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.


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:

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:

each of those classes inherit from interface:

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:

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