Is it more correct to use the Master-Detail concept?

Question

Is it more correct to use the Master-Detail concept?

Navigation

#1 by (0 votes)

1

I have a situation that I would like to use the most correct (elegant) way to implement. The scenario is as follows:

I'm building a HelpDesk system where Tickets are stored in a table (and consequently has its own Model) and the Ticket evolutions are stored in another.

The implementation I'm doing is with C # using MVC and Razor

I have already done View of ticket listing and clicking on it I go to another one that presents details with information of title, content, sector that registered and user.

I would like to bring along with this View of details the history of evolutions (and even register new evolutions regarding the ticket) and it is precisely in this that I am having difficulties (gather in a single View information of model ticket and% of% evolucoes).

Below are the structures assembled for better understanding: MODELS

public class ticket
{
    [Key]
    public int id_ticket { get; set; }
    public int id_setor { get; set; }
    public int id_usuario { get; set; }
    public string assunto_ticket { get; set; }
    public string prioridade_ticket { get; set; }
    public string mensagem_ticket { get; set; }
    public DateTime data_ticket { get; set; }
    public string status_ticket { get; set; }
}


public class Evolucao
{
    [Key]
    public int id_evolucao { get; set; }
    public int id_ticket { get; set; }
    public int id_usuario { get; set; }
    public string texto_evolucao { get; set; }
    public DateTime data_evolucao { get; set; }
}

c# view asp.net-mvc visual-studio-2013

asked by anonymous 18.03.2017 / 13:27

1 answer

Firebase Auth with Facebook - Save information in RealDatabase Wrong position of posts in Wordpress

score 0 · Answer 1

Marcelo you can use ViewModel pattern.

In case of using information from two Models in the same view you can create a ViewModel that contains the two or more Models.

The ViewModel should not have methods, only properties needed for the view. Then your view will work with this ViewModel and your controller should do all the work of loading / unloading this ViewModel with the Models data.

If I understand your example, each ticket can have several evolutions, so your ViewModel should load the ticket in question and a collection of its evolutions.

    public class EvolucaoDoTicketViewModel
{
    public Ticket Ticket { get; set; }
    public IEnumerable<Evolucao> Evolucao { get; set; }
}

In your controller you should load the ticket in question and the collection with the evolutions related to your id.

You can work with this data in your view and then in the controller (in case of modifying the data for example) "unload" the data of the ViewModel in the corresponding models and save them.