RenderAction in MVC

Recently I was debating with my friend about using RenderAction methods instead of rendering partial views. One could say, what the fuzz is all about. It’s all about simplicity. Rendering some part of your page with partial, makes you create big, fat model, passing its parts all around (for instance Model.SthForFirstPartial, Model.SthForSecondPartial). It can bring you to one model per one view or even action and this is baaaad.
You have an alternative: you can simply render actions results in you parent view using mentioned methods. Advantages:

  • only atomic values passed (for instance, post id to render its comments)
  • atomic actions (like: Comments, a list of comments) with results rendering not full-blow html, but parts of it (JSON is also applicable in here)

It seems, that this would be all, but it is not. Using NHibernate, my favourite ORM, and having it instantiated once per request (for Windsor fans: LifestyleType.PerWebRequest) I can easily fetch needed data in the parent action, loading it in a session first level cache. The child action then, will simply get data already fetched, having no problems with getting to many hits on your db.

I do like this paradigm.

For disassemblers
(the people, which overuse Reflector, or its free replacements, to read code), there’s a few lines of code, which passes the original HttpContext with all its Items (yeah, that’s the base for having LifestyleType.PerWebRequest working), an excerpt from ChildActionExtensions
class:

var httpContext = htmlHelper.ViewContext.HttpContext;
var context = new RequestContext(httpContext, data2); // whoa! I'll get my request items back!
var httpHandler = new ChildActionMvcHandler(context);
httpContext.get_Server().Execute(HttpHandlerUtil.WrapForServerExecute(httpHandler), textWriter, true);

Reviewing code

Recently I’ve been introducing a code reviewing tool, called Review Board. The whole ‘review’ thing was inspired by a free copy of Best Kept Secrets of Peer Code Review . The aim was to empower my team with a tool, which will allow propagating best practices easily. The other, obvious target, was ensuring quality of a software being developed. In a few next posts, I’ll describe the whole process, as well, as a team accommodation.

The book
The paper version of the book was sent for free. I was astonished that one company can afford such a gift. I do understand that Smartbear released their revision tool called Code Collaborator, but… come on. A book for free? It’s nice of them. Speaking about this position, it’s a must read for anyone who wants to introduce reviewing in his/her team. The book covers some research done in a combat conditions which can be valuable for your manager, if you have problems with incorporating a new thing into your tech toolbox. The numbers show, that reviewing is much more valuable than writing tests. I know, it can harm some zealous TDDers, but you should take into consideration by every developer thinking seriously about his/her craft.

The tool
As I scanned the Code Collaborator pricing I knew, that my company won’t cover costs for the whole team. I searched for some replacement and found the Review Board. The application is written entirely in Python and the server part is destined to be installed on a Linux environment. We’ve managed to make it run in less than one day. Then, the time came to integrate it with VisualSVN hosted on a Windows 2003 server. The VisualSVN has a nice support for post-commit hooks. It passes two parameters to the hook body. Although they can be easily passed to your batch, exe, whatever with a simple property window, it took me a while to get all the needed data to match the post-review, as it needs for instance a revision range for which the diff will be generated. Finally, I’ve got it running.

The team
As always I tried to be the change. The reviewing after a small number of delays became a habit. Receiving emails helps with this, as each review request is notified with a short email with a request summary. The whole process made the whole team to write better commit comments as no-one wants to be asked (at least, I wouldn’t like) “what did you just commit?”. It seems, that beside measured factors, the code review empowers a team as a whole. The journey goes on!