Retornando uma entidade de domínio reduzida do seu modelo de visão

5

Eu estou querendo saber como lidar com um ViewModel no sentido tradicional, que inclui propriedades e métodos, e outro "modelo de exibição" que é simplesmente as propriedades - talvez o ViewModel retornaria uma visão "entidade" ", ou algo assim.

Deixe-me explicar:

Modelo de domínio:

public class Workout 
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string SomethingElse { get; set; }
    public List<Exercise> Exercises { get; set; }
    public DateTime CreatedDate { get; set; }
}

Ver modelo:

public class WorkoutHistoryViewModel : IWorkoutHistoryViewModel
{
    private IWorkoutRepository workoutRepository;

    public WorkoutHistoryViewModel(IWorkoutRepository workoutRepository)
    {
        this.workoutRepository = workoutRepository;
    }

    // Here I'd like to return a slimmed down entity, not the full entity
    public IEnumerable<WorkoutHistoryViewEntity> GetExistingWorkouts()
    {
        return this.workoutRepository.GetList(); // some mapping logic
    }
}

E talvez a "entidade de visualização" desejada seja apenas:

public class WorkoutHistoryViewEntity 
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Também precisarei fazer algo semelhante para, digamos, um WorkoutDetailsViewModel , que exigirá um conjunto diferente de propriedades para o "modelo de exibição", como:

public class WorkoutDetailsViewEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<Exercise> Exercises { get; set; }
}

Então, eu acho que as perguntas são:

  1. Estou fazendo o MVVM errado? Este ViewModel também deve ter as propriedades desejadas? Em caso afirmativo, quando faço um GetExistingWorkouts() , devo retornar um List<WorkoutHistoryViewModel> ? Nesse caso, eu tenho um monte de objetos, todos com repositórios e métodos, quando na verdade eu só quero os dados.
  2. Se eu deveria criar uma terceira classe, como o WorkoutHistoryViewEntity , o que é normalmente chamado (como o ViewEntity não soa bem).
por Tom 24.06.2015 / 15:46
fonte

2 respostas

3

Você não precisa se preocupar com o fato de seus ViewModels terem mais funcionalidades do que apenas fornecer dados. Isto é, afinal de contas, sua verdadeira função - fornecer os dados para exibição e qualquer funcionalidade exigida pela Visualização. O ViewModel normalmente conterá propriedades, ICommands, pelo menos um modelo e quaisquer referências a serviços e repositórios necessários para lidar com modificações no modelo.

No seu caso, seu WorkoutHistoryViewModel fornecerá um ObservableCollection<WorkoutViewModel> , cada um com um objeto Workout como modelo.

para responder às suas duas perguntas:

  1. Você está fazendo muito bem o MVVM. Não se preocupe com isso, parecendo um pouco detalhado - há razões para a separação. E quase todos os viewmodels terão algumas referências a serviços e dados.
  2. Não crie um "ViewEntity". Basta criar um ViewModel.
por 24.06.2015 / 16:14
fonte
1

Retornar um List<WorkoutHistoryViewModel> parece não ser o melhor caminho para mim, mesmo que seja feito com frequência. Sua segunda opção é melhor, e acho que você entendeu isso corretamente pela intuição.

Você tem razão, porém, de que WorkhoutHistoryViewEntity não é um nome apropriado. Pode significar quase tudo. É difícil encontrar um nome para o Id e o nome porque o primeiro é técnico e o segundo não é. Eu assumo aqui que o Id é único e o nome não é. Neste caso, há provavelmente uma maneira de retornar apenas uma lista de nomes ou uma lista de IDs? Isso poderia resolver seu problema, porque eu me pergunto se há uma boa razão para retornar as duas informações juntas. Se houver um bom motivo, dizer-nos pode tornar mais fácil encontrar um bom nome. Senão você também pode ir com WorkoutIdAndName .

Se ambos Id e nome forem exclusivos, vá com WorkoutReference ou WorkoutIdentifier (e também use essa classe interna para armazenar ID e um alias (aqui seria o nome)).

    
por 24.06.2015 / 16:16
fonte