Is html.renderaction code smell

Question

I've recently started a new job where I've been thrown into a bug fixing role on an under development ASP.Net MVC application. I'm a big fan of using an MVC approach for web apps and built some hefty production apps on Maverick.Net starting back in 2004/2005 however this is my first time using the ASP.Net MVC framework for anything other than mucking around.

One thing I'm finding myself doing a lot with the bug fixing is chasing through chains of controllers following the html.renderaction calls. In the past when I've written MVC apps a single controller would be responsible for producing the model in it's entirety. If there were common sections or functions for each controller they'd be sub-classed, moved into the data access layer. It seems to me that in this case, and I suspect others, that having html.renderaction is going to encourage some seriously spaghettified code and really defeats the purpose of having the distinct C-M-V stages since it now becomse C-M-V-C-M-V-C-M-V etc.

Is html.renderaction really the best way to encourage clean code, it seems a bit smelly to me?

Answer 1

" bug fixing is chasing through chains of controllers following the html.renderaction calls."

Oh god. That sounds horrible.

Pretty sure this is smelly. RenderAction is just for those "advanced widget" scenarios.

Answer 2

I think it is wise to try not to use all of this helpers, integrated or customly written, as much as you can. It is like a handy shortcut to solve things in design quickly, but then what you are really doing is making big mess.

Answer 3

After some more time working on the project and with the ASP.NET MVC framework the conclusion I have come to is that RenderAction should not be used in production code (maybe there's an exception to that rule but I haven't come across it yet) and instead use RenderPartial and supply the model with the call to it.

That way there is only ever one controller stage which makes maintenance much easier and additionally the single controller stage can make sure any expensive operations, such as database interactions are as efficient as possible, something which can't be done if the processing is spread across multiple controller stages. By using RenderPartial mutliple chunks of view logic can be used to adhere to the DRY principle which keeps the main advantage of RenderAction but without the two big downsides.

Bad:

Html.RenderAction("ViewName", "PersonName", new { id = Model.Person.ID });

Good:

Html.RenderPartial("ViewName", Model.Person.Name);