Is binding domain models directly a bad idea?

Question

I'm curious if binding models directly as parameters in the action method is considered as bad idea ?

If the form gets to complex, I could create a custom model binder.

Are there any pitfals using this approach ?

I'd like to avoid creating of viewmodel, because I want to keep me app as simple as possible. I'd like to avoid of duplicating the code and the modelview to model binding.

Answer 1

I'd advise to almost always use view models.

If you're using the default object templates... they don't really like non-flat models, and while you could override them, it's not always a good idea. Domain Models are usually not flat. Either way, anything based on ModelMetaData is easier with a ViewModel.

Validation is also easier with a ViewModel, as you've got a more focused model, and sometimes there's validation that only makes sense in some views.

Creating ViewModels is much better and safer then sending models using JsonResult... Well... you should NEVER send Domain Models outside anyway, even if you're not using ViewModels. But it's easier using JsonResult when you've got a ViewModel ready. It's also easier to make mistakes and expose sensitive information when you're used to using your domain models everywhere.

Changes are sometimes easier, because changing a property on the Domain Model doesn't mean you have to change all your views, just change the creation of the ViewModel (if you're using some kind of mapper, that's just one change to the binding), although this isn't a very strong point IMO.

Some other benefits are decoupling the presentation layer from the business layer, and if you're using EF or non-poco objects, it'll be harder to use them in views.

If you want to eliminate duplication of code, you could consider creating filters that automatically create your ViewModels, and even without action filters using a mapper does eliminate a lot of code duplication.

BTW, I don't see how creating a custom model binder is simpler than using ViewModels.

Answer 2

Not necessarily. But soon you will find some state which needs to be on the model but is UI specific and you end up creating a ViewModel anyway.

Also for some properties such as DateTime, this would not work well on the Model if defined as DateTime since there is a problem with making it optional so you have to define it as string. And I do not believe you wanna put string for a date.

Additionally, for DropDown items you need to have a collection on the Model for the SelectListItem which does not make sense on the Model.

That's what happened to me.

Answer 3

I would advise you to always create a ViewModel. In its simplest form it might simply contain a property with the domain object (and accessory data). Something like:

public class DomainModelClass
{
    int Property1 { get; set; }
    int Property2 { get; set; }
}

public class ViewModelClass
{
    DomainModelClass DomainModel { get; set;}

    SelecList List1 { get; set; }
}

Anyway, this suggestion is just to keep things simple, because I would advise you to create a "real" viewmodel, and use something like AutoMapper to map the ViewModel <-> DomainModel, even in a simple scenario.