Supervising Controller Pattern Understanding

Question

I'm trying to use the Supervising Controller pattern in a simple web application. My view is a sign up form and has many fields for a user to input (Think several pages of gmail sign up) This data will populate an entity, and this entity is processed when the user has submitted it.

For Example:

public interface ICreateAccountView
{
    string firstname { get; set; }
    string lastname { get; set; }
    string loginName { get; set; }
    string password { get; set; }
    string addressLine1 { get; set; }
    string addressLine2 { get; set; }
    string postCode { get; set; }
    IList<string> preferences { get; set; }
    .... Many others omitted
}

I have a couple of questions on this:

1) Should I have properties on my view like this when I have so many? Should I not just use the entity object that I'll populate anyway?

2) As this data will eventually populate an entity object should my controller hold the reference to this object?

Any help or advice would be appreciated.

Answer 1

There is no reason to not have a method on the view that your controller can call into that returns all of the view data in the form of the entity. As long as the controller is asking for the data you should be ok!

Now for the purists out there. They would prefer that you not return an "entity" from the view. Instead try to return a view object (or dto/data transfer object) so that the view really has no concept of your middle tier/domain objects. This decouples the view from your business tier a bit more.

Depends on how big this app is and how deep in the patterns rabbit hole you want to go.