5

I've see a lot of MVC examples where domain-objects are passed directly to views, this will work fine if your view is simple.

The common alternative is to have a view-model which has all the same properties as your domain-model + any extra properties your view may need (such as 'confirmPassword').

Before doing too much reading and before discovering AutoMapper I started creating my own variant of view-model where the domain-object (or multiple domain objects) are simply properties of the view-model.

Have I done a bad thing? What problems or benefits could be derived from this approach? Under what circumstances might this way of doing things work well?

Myster
  • 17,704
  • 13
  • 64
  • 93
  • if you're encapsulating the Domain-Model, than what's the purpose of the ViewModel – Omu May 05 '10 at 19:04
  • The main reason was to aggregate multiple domain-models, eg: Product, Basket, Navigation etc – Myster May 05 '10 at 20:50

2 Answers2

4

There's nothing inherently bad about exposing your domain model directly to the view. The primary risk comes from exposing a property you didn't mean to, like a salary field on an Employee object. Be sure to watch out for this if you're returning JSON.

Another thing to watch out for is when you're binding back from an edit form. You should be aware about the specific risks that are involved. Basically a malicious user could add fields to the POST that happen to match fields that you didn't mean to be editable. I always bind to an intermediary object which is passed into a service before mapping it back to the domain.

Ryan
  • 4,303
  • 3
  • 24
  • 24
  • This only applies to domain objects that are action parameters; there's nothing insecure about passing them to views. – queen3 Apr 08 '10 at 11:34
  • @queen There are two separate concerns. Outgoing: exposing sensitive fields through JSON/XML/whatever. Incoming: malicious form parameters. – Ryan Apr 08 '10 at 21:43
  • I recall someone advocating the viewModel is the SAME type as the Action parameter for postbacks. It seems that approach means you must separate your Domain model completely. (unless it's intended to be entirely open to modification) – Myster Apr 11 '10 at 23:13
  • @Myster There are some people who advocate that. I've actually gone one step further in some complex cases by having separate (but similar) output and input models. Yes this does separate your domain entirely but that is my goal. Isolating the domain makes me think about exactly what the user is going to be doing, plus I only have to put security in one spot, the service layer. – Ryan Apr 11 '10 at 23:43
  • I'm finding that using a DDD approach where i use my Factories to instantiate my model objects (that _are_ passed to my views) i avoid the particular issues you refer to with POST form collections - i _need_ custom model binders so that my Factories understand how to create objects and so this enforces constantly valid and safe domain model object instances. – Matt Kocaj Feb 25 '11 at 08:09
  • @cottsak Here's a very simple example of how we do things. http://gist.github.com/844100 The reason we use update models is because we are often times only modifying a small part of an aggregate. We would only use a factory when initially creating the domain entity (and then only if we can't get by with a static creation method). – Ryan Feb 25 '11 at 17:12
  • @Ryan Why are you doing in your gist. sample the CRUD-Get method on your repository interface but the .Update you do with the trade domain object. – Pascal Jul 15 '12 at 18:02
0

Bad? Can't use Automapper. ;)

Good? Nothing comes to mind.

I don't think you've done anything horrible. Does it work for you? If so then why not?

John Farrell
  • 24,673
  • 10
  • 77
  • 110