design do modelo MVC / herança

Question

Perdoe a vaga título, eu não tinha certeza de como descrevê-lo.

Se você tem um modelo genérico de "Arquivo", como você mostrar diferentes visões / formulários com base em um usuário selecionado 'tipo'?

Por exemplo, o usuário cria um novo "Arquivo", em seguida, recebe a opção de vídeo, livro, áudio etc. De lá, eles obter diferentes formas com base no tipo de arquivo.

Ou seria melhor para dividi-los em diferentes modelos - Vídeo, Livro, áudio?

ou pode modelos herdam (como vídeo estende Archive). Eu acho que isso é OOP / classes básicas, mas não têm idéia de como aplicar esse aqui.

Exemplos de qualquer framework MVC são bem-vindos!

Answer 1

Parece que você não gostaria de ter a herdar Tipo de Arquivo. "Sempre favor encapsulamento / contenção sobre a herança".

Por que não criar uma classe chamada Archive e dar-lhe uma propriedade tipo. O tipo pode usar a herança para se especializar para áudio, vídeo, etc.

Parece que você se especializar Arquivo com base em alguns outros critérios. "FileSystemArchivce", "XMLArchive", "SQLArchive" e do tipo não mudaria. Mas o agilista em mim diz que este pode não ser necesscary em primeiro lugar, e você sempre pode refatorar o design mais tarde ...

Em termos de um controlador, você provavelmente obter o maior retorno para os investimentos, encapsulando as diferenças de apresentação para cada tipo na exibição. Assim, apenas o ponto de vista muda de acordo com o tipo. Propensos a semântica e as regras para cada um são os mesmos e você não precisa ter controladores separados para cada tipo. As opiniões serão diferentes para cada tipo, uma vez que terá diferentes atributos.

Answer 2

Para realmente mostrar uma visão diferente deve ser fácil em qualquer framework MVC. Por exemplo, no Microsoft ASP.NET MVC você não apenas retornar uma vista de um controlador como o seguinte:

return View();

mas seria realmente indicar o nome da vista como um parâmetro:

return View("VideoArchive");

que passaria então a mostrar a vista de Visualizações / Arquivo / VideoArchive.aspx

Answer 3

Seus modelos Vídeo, Livro e Áudio pode herdar de Arquivo.

E cada modelo terá um controlador.

http: // yourserver / Livros / Editar / 11

Você terá que obter o seu usuário escolher o tipo de arquivo que deseja antes de criar o modelo correspondente.

Editar (em resposta ao comentário)

Em ASP.NET MVC seu modelo será uma classe.

public class Video : Archive
{  
    public int Id {get;set}
    public string Name {get;set;}     
    ...
}

Você também terá um controlador

public class VideoController : Controller
{
    public object Edit(int id)
    {
        Video myVideo = GetVideo(id);
        return View("Edit", myVideo);
    }
     ...
}

E você terá uma vista no diretório Visualizações por exemplo, a página que contém

public class Edit : View<Video>
{
    ...
}

Assim, você pode chamar isso se você tivesse uma URL que era

http: // localhost / Vídeo / Editar / 11

Isso tudo foi feito a partir da memória, portanto, pode haver alguns erros, mas a mensagem para levar para casa é que você especificar a herança para o modelo. O modelo é apenas uma classe. No seu caso, você quer herdar de Arquivo. Depois de ter feito que o modelo é passar em torno de como normal.

Answer 4

Parece-me que um ponto sólido em favor da MVC é que você pode não precisar de personalizar o modelo (ou o controlador - dos quais você quer apenas um) se todas as necessidades do usuário é uma visão diferente. Vários modelos que aparecem somente se a arquitetura de armazenamento (persistência) ditou uma necessidade para ela. Alguma característica como objetos de acesso a dados (DAO) seria potencialmente aparecer como outra camada, entre o controlador e o modelo, você deve exigir vários modelos.

Dê uma olhada na projeto Apache Struts para exemplos. Como indicado no do Struts para Iniciantes , "Para usar Struts bem, é importante ter uma boa compreensão dos fundamentos. Comece por rever o Principais Tecnologias cartilha , e estudar todos os tópicos desconhecidos."

Por outro recurso, consulte Web-Tier Aplicação quadro projeto (Sun J2EE Blueprints)

Answer 5

O único princípio Responsabilidade (PDF) afirma que:

Não deve nunca ser mais de uma razão para uma classe de mudar.

Sua classe Arquivo viola este princípio por lidar com vários tipos diferentes de arquivos. Por exemplo, se você precisa atualizar o arquivo de vídeo, você também modificar a classe que lida com livro e arquivos de áudio.

A maneira apropriada de lidar com isso é criar classes separadas para cada tipo diferente de arquivo. Estes tipos devem implementar uma interface comum (ou herdar uma classe base comum) para que possam ser tratados de forma intercambiável (polymorphically) pelo código que só se preocupa com Arquivos, não tipos de arquivo específico.

Depois de ter essa hierarquia de classes no lugar, você só precisa de um único controlador e vista para cada classe de modelo.

Para pontos de bônus, o princípio da responsabilidade única pode até justificar o uso de um método de fábrica ou de fábrica abstrata para a criação de seu modelo, vista e objetos de controlador (em vez de nova-ing-los in-line). Afinal, a criação de um objeto e usar esse objeto são diferentes responsabilidades, o que pode precisam ser alteradas por razões diferentes.