tags:

views:

58

answers:

2

I'm in the process of converting parts of an application to use ASP.NET MVC from WebForms. The idea is that when possible I use MVC for new development. My problem is this:

Doing it this way means that my Models are not completely implemented in MVC. Let's say that my WebForms application has a robust Widget Management page. I'm adding new functionality to attach a color to a Widget. Click a widget, and it brings you to a new page to select a color, and that's all. One field. It seems silly to create a WidgetColorPreference Model with two properties: WidgetID and Color, for the sole purpose of validating and saving.

So, I have gone down the road of implementing a Service namespace with methods such as "SetWidgetColor", accepting a WidgetID and Color parameter. My controller action simply calls that service in my Models assembly.

My question: Is this a valid stopgap architecture?

+3  A: 

Sure. MVC exists to put a view on top of a model. If your app is all view and no model, you don't need to force a model in there. As your app gets more complex, and there becomes an obvious model, you can re-factor.

In other words, you wouldn't use M, V and C for Hello World. It would strictly be "V". "C" adds more view-specific smarts, and "M" adds business logic, persistence and retrieval.

Brian Genisio
A: 

I think you'd use a Widget model and then use the Include/Exclude features of the model binder to just update those properties on the Widget model in your action.

public ActionResult UpdateWidgetColor( [Bind(Include="Color,ID")]Widget widget )
{

}

or something similar using TryUpdateModel

public ActionResult UpdateWidgetColor( int id, string color )
{

   var whitelist = new string[] { "Color" };

   Widget widget = db.Widgets.SingleOrDefault( w => w.ID == id );

   if (widget == null) ...handle missing widget error

   if (!TryUpdateModel( widget, whitelist ))
   {
      ...
   }
   else
   {

   }
}
tvanfosson