2

Let's say i've got the following absurd viewmodel in a MVC application.

public class Absurd
{
  public string WelcomeMessage {get; set;}
  public string PlainTextAdminPassword {get; set;}
}

And this is the entirety of my view

<div>@Model.WelcomeMessage</div>

Let's assume that both my WelcomeMessage and PlainTextAdminPassword are populated in a controller.

Is PlainTextAdminPassword going to be sent to the client anywhere? Or does MVC only send portions of the ViewModel that are referenced in the View?

|improve this question
  • "i've got the following absurd viewmodel…". I agree. Having setters on a viewmodel in MVC is absurd ;) – David Arno Nov 6 '18 at 14:12
  • @DavidArno Can you explain why you think that? Would a big constructor be better for some reason? – neilsimp1 Nov 15 '18 at 13:03
  • @neilsimp1, the view should only ever read from the viewmodel. It should not be modifying it. Therefore why have (public) setters? There are various ways you could deal with this: use a getter-only interface and pass that to the view, use a "big constructor" as you suggest, use a builder, have internally accessible setters and separate the logic of constructing the viewmodel into a different assembly to the view. There may be others that I've not thought of, each of which has its own pros and cons – David Arno Nov 15 '18 at 13:16
  • @DavidArno Fair point. I would probably just not set any values on the ViewModel from the View, but it is a good argument I had never thought of. I really like the idea of "separate the logic of constructing the viewmodel into a different assembly". – neilsimp1 Nov 15 '18 at 13:24
5

The razor view is passed a reference to the Model, which is used to generate the HTML, which is sent to the client.

The Model and its properties are not sent to the client unless you render them out in some way

|improve this answer
-3

The programming precisely determines what will be passed, out of what could be passed.

Since your Model prescribes that PlainTextAdminPassword is public, this means that it, also, "could be passed," and "the model knows not where!"

(If you're not 100%-comfortable with that, "don't make it public!")

|improve this answer
  • Not having properties as public tends to defeat the purpose of having them in a model to begin with. Unless they are used as part of another public property, but then that becomes the same "issue" as if the password itself had been public. – Flater Nov 6 '18 at 14:25
  • Since your Model prescribes that PlainTextAdminPassword is public, this means that it, also, "could be passed," "could" is not an answer to the posted question since OP gave a precise example of where the password field is not actually used on the view. In that case, the answer is no. – Flater Nov 6 '18 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.