I have the following Entities and ViewModel (some properties removed for clarity):
Ticket:
public class Ticket
{
[Key]
public int ID { get; set; }
public string Comment { get; set; }
//Navigation Property
public virtual ICollection<Attachment> Attachments { get; set; }
}
Attachment:
public class Attachment
{
[Key]
public int ID { get; set; }
//Foreign key for Ticket
public int TicketID { get; set; }
public byte[] FileData { get; set; }
public string FileMimeType { get; set; }
//Navigation Property
public virtual Ticket Ticket { get; set; }
}
TicketViewModel:
public class TicketViewModel
{
//Default constructor
public TicketViewModel()
{
}
//Constructor with parameter
public TicketViewModel(Ticket ticket)
{
Ticket = ticket;
Attachment = new Attachment();
}
public Ticket Ticket { get; set; }
public Attachment Attachment { get; set; }
public virtual ICollection<Attachment> Attachments { get; set; }
}
In the Create a new Ticket page, there is also attachment field and multiple attachments can be added to this newly created ticket. For this reason I use TicketViewModel and pass Ticket
and ICollection<Attachment>
to the controller. On the other hand, I am not sure if I am wrong, because I can pass just 'Ticket' to the controller and create a new instance of TicketViewModel
in the controller by passing Ticket model to the constructor of TicketViewModel. In this scenario, what approach should I follow?
Note: I pass IEnumerable<HttpPostedFileBase>
to the controller for Attachment data.
Update:
I updated View and pass Model instead of ViewModel as shown below:
View:
@model Ticket
//... some other stuff
And in the controller, I pass the filled Model and new instance of the Attachment Collection to the method in the data layer as shown below.
Controller:
List<FileAttachment> fa = new List<FileAttachment>();
While the real answer is subjective and based entirely on personal preference, I will give you my answer and reasons.
Passing a so-called View Model is typically better than passing an Entity POCO, due to the fact that the page/forms will likely require more data than is used in the POCO.
In the case you provided I would flatten the classes in a View Model by merging the properties into one class for easy binding, and then create a
Process()
function to provide the two POCOs I needed. Usually when working complex models theProcess()
function will return a new Domain Model to save, or accept a Domain Model to edit.For example, you may want to provide cheap bot protection in the form of an arithmetic problem that wouldn't need to be saved anywhere. Passing a View Model can also limit the exposing of data, in case the person doing the back end stuff is different from the person laying out the Views.
In most cases, though, the POCO can be just fine. I personally tend to pass View Models for complex data, and the actual POCO for small tables, like when the only two columns are a UID and a text field.