Reusable Domain Controls in MS MVC

by coatta 2/2/2012 9:39:00 AM

Most of the example code for MVC that I have seen out there isn't well-suited to creating re-usable UI components -- in particular components that are application specific, but may want to be used in multiple contexts within the applications. For example, a component that displays a list of customers might be used on a number of different pages within the application. But it is possible to build re-usable components of this sort, you just have to follow a few rules which help ensure that the component is not coupled to the page that it resides on.

So, the rules are:

  • View models should always include a field for the ID of the target element
  • Always use RenderPartial() - Links need to be rendered with Ajax.ActionLink()
  • Forms need to be rendered with Ajax.BeginForm()
  • Forms/Links need AjaxActions with the target element set appropriately

Components always need to render into a specific HTML element on the page. The container (the page using the control) determines where it wants the control to display and passes this in as a parameter. The component thus knows where it should be rendered, but is ignorant of anything else on the page. If the component needs to include other components as part of its display, these should be rendered via Html.RenderAction(). In this case, the component is acting as the container, and so it must determine which HTML element the sub-component will render into. Obviously, this should be an HTML element defined in its cshtml file.

In general, components should not include links that would navigate to completely new pages. Instead, these links should simply route back to controllers/actions that have been given to the component as parameters -- it is the container's job to deal with global navigation, not the component.

MVC 3 and DependencyResolver - The Ecstasy and the Agony

by coatta 8/19/2011 2:32:00 PM

I started building my first MVC 3 the other day and came across the DependencyResolver mechanism for incorporating 3rd party inversion of control containers. How I rejoiced! I've been using Castle/Windsor for quite some time and have a nice set of capabilities built on top of its interceptor feature. So, I pull in my utility library, grab a Windsor-specific implementation of IDependencyResolver off the net, and start setting up my constructors for injection. I run my sample app, and it all hangs together. My controllers are being instantiated through Windsor and I'm happily making use of my utilities for tracing, logging, timing, etc.

Now its time to make my little sample a little more realistic. I add some model classes, make my views strongly typed, add some forms which submit data back to the application. Its all pretty straightforward, so I am not expecting any problems when I start it up and navigate to the main page. Sadly, it dies. There is an error message about not being able to create an object because a parameterless constructor cannot be found. Naturally, the error message doesn't tell me which class is causing this problem... After a bit, I find that the problem is my new model objects, but that doesn't really make sense because Windsor shouldn't be looking for a parameterless constructor.

I'm puzzling this out when it hits me: The model objects are not being allocated through Windsor, MVC is instantiating them directly. My rejoicing turns to despair. How could they go to all the trouble of setting up an infrastructure to support inversion of control and then not use it uniformly!? OK, I get that model objects are basically data bags and probably shouldn't be referencing services, but an IoC framework is more than just a way to resolve services. As noted above, I've got a bunch of utilities for tracing, timing, debugging, etc. that are all built on top of the core capabilities of Castle/Windsor. And those utilities are useful for model objects. But I can't use them because someone on the MVC team decided that it didn't make sense to use the dependency resolver for model objects.

Now its off to see what other ways MS can inflict emotional damage on me...


<<  June 2024  >>

View posts in large calendar


My opinions are my own, but you can borrow them if you like.

© Copyright 2024

Sign in