É a minha aplicação ASP.NET MVC estruturado adequadamente?

Question

Eu tenho ido através dos tutoriais (especificamente aqueles que usam LINQ to Entities) e eu entendo os conceitos básicos, no entanto, algumas coisas estão me dando problemas.

Os tutoriais geralmente envolvem apenas os modelos e formas simples que só utilizam básica criar, atualizar e instruções DELETE. Os meus são um pouco mais complicado, e eu não tenho certeza que estou lidando com isso da maneira certa, porque quando chega a hora de lidar com as relações de uma meia dúzia de objetos de banco de dados, os tutoriais parar de ajudar.

Para o método post, a maneira usual de realizar operações CRUD

entities.AddToTableSet(myClass);
entities.SaveChanges();

Não vai fazer o que eu quero, porque uma classe totalmente implementado não está sendo enviada para o método de controlador. I pode postar campos individuais, coleções de formulário ou vários objetos DTO e, em seguida, chamar um método em um serviço ou repositório de levar a informação que recebo de um post de formulário, juntamente com as informações de que necessita para consultar ou criar a si mesmo, e depois de todas essas coisas, criar meu objeto de banco de dados que eu posso salvar.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Add(int id, [Bind(Exclude = "Id")] ClassA classA,
                        [Bind(Exclude = "Id")]ClassB classB)
{
   // Validation occurs here

   if(!ModelState.IsValid)
      return View();

   try
   {
      _someRepositoryOrService.Add(id, classA, classB);
      return RedirectToAction("Index", new { id = id });
   }
   catch(Exception ex)
   {
      // Logging and exception handling occurs here
   }
}


public void Add(int id, ClassA classA, ClassB classB)
{
    EntityA eA = new EntityA
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    EntityB eB = new EntityB
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    _entity.AddToEntityASet(eA);
    _entity.AddToEntityBSet(eB);
    _entity.SaveChanges();
}

Am I lidar com isso corretamente ou estou bastardizing quadro? Eu nunca realmente usar um objeto de entidade diretamente, sempre que eu consulta para que eu colocar a informação de que preciso em um DTO e basear minhas opiniões fora dessa. O mesmo acontece com a criação. Isso é permitido, ou é a minha evasão de usar entidades diretamente indo contra o propósito de usar o framework?

Edit: Eu também estou preocupado com esta abordagem, porque exige construtores vazios para fazer corretamente as consultas LINQ devido a esta mensagem de erro:

Apenas sem parâmetros construtores e initializers são suportados no LINQ para Entidades.

Este não é um grande negócio desde que eu raramente precisam lógica int os construtores, mas isso é uma questão de ter nenhum construtor e apenas propriedades públicas?

Answer 1

_someRepositoryOrService.Add (id, classA, ClassB);

Eu diria que você par de seus repositórios com camada de apresentação. Isso não deve ser. Seus repositórios só deve trabalhar com entidades. Em seguida, observe como o seu método Add

Add public void (int id, ClassA classA, ClassB ClassB)

breaks separação de interesses (SoC). Ele executa duas tarefas:

1. Mapa de dados em entidades
2. Salvar para repositório

Obviamente, o primeiro passo deve ser feito na camada de apresentação. Considere o uso de ligantes modelo para isso. Ele também pode ajudá-lo a resolver o problema construtores, pois suas pastas modelo pode ser feita ciente dos requisitos de construção.

Verifique também este excelente mensagem por Jimmy Bogard (co-autor do ASP.NET MVC em Ação) sobre ViewModels. Isso pode ajudá-lo a automatizar o mapeamento. Também sugerem uma técnica invertida - fazer seus controladores de trabalho com as entidades, não ViewModels! filtros de ação personalizados e pastas modelo são realmente a chave para eliminar rotina que que realmente não pertencem aos controladores, mas sim um detalhe infra-estrutura entre a visão e controlador. Por exemplo, aqui 's como eu automatizar entidades retrival. Aqui 's como eu ver o que os controladores devem fazer .

O objetivo aqui é fazer com que os controladores contentrate sobre o gerenciamento de lógica de negócio, deixando de lado todos os detalhes técnicos que não pertencem ao seu negócio. É restrições techical que você falar nesta questão, e você deixá-los vazar em seu código. Mas você pode usar ferramentas MVC para mover o que lhes nível de infra-estrutura.

UPDATE: Não, repositórios não devem manusear os dados do formulário, que é o que eu quero dizer com "acoplamento com apresentação". Sim, repositórios estão no controlador, mas eles não funcionam com dados do formulário. Você pode (não que você deve) make forma de trabalho com "dados Repositórios" - entidades ou seja - e é isso que a maioria dos exemplos fazem, por exemplo, NerdDinner - mas não o contrário. Isso é por causa da regra geral - camadas mais altas pode ser acoplado com os inferiores (apresentação juntamente com repositórios e entidades), mas nunca de baixo nível deve ser acoplado a outros mais elevados (entidades dependem de repositórios, repositórios depende do modelo de formulário, etc ).

O primeiro passo deve ser feito no repositório, isso é certo - exceto que o mapeamento de ClassX para EntityX não pertence a esse passo. É mapeamento preocupação - uma infra-estrutura. Ver, por exemplo esta questão sobre o mapeamento, mas geralmente se você têm duas camadas (UI e repositórios) eles não devem se preocupam com mapeamento - um serviço mapeador / ajudante deveria. Ao lado blog de Jimmy, você também pode ler ASP.NET MVC em Ação ou simplesmente olhar para o seu CodeCampServer para saber como eles fazem mapeamento com interfaces IEntityMapper passados ??para construtores controlador (note que este é mais manual e menos trabalho abordagem que AutoMapper de Jimmy Bogard).

Só mais uma coisa. Leia sobre Domain Driven Design, olhar para artigos, aprender com eles, mas você não tem que seguir tudo. Estas são linhas de orientação, não soluções rigorosas. Veja se o seu projeto pode lidar com isso, veja se você pode lidar com isso, e assim por diante. Tente aplicar estas técnicas, uma vez que são geralmente as formas excelentes e aprovados de fazer o desenvolvimento, mas não levá-los cegamente. - É melhor para aprender ao longo do caminho do que aplicar algo que você não entende

Answer 2

Eu diria usando DTOs e envolvendo o Entity Framework com os seus próprios métodos de acesso a dados e camada de negócios é um grande caminho a percorrer. Você pode acabar escrevendo um monte de código, mas é uma arquitetura melhor do que fingir o código Entity Framework gerados é a sua camada de negócios.

Estas questões são realmente não necessariamente ligada a ASP.NET MVC de forma alguma. ASP.NET MVC dá basicamente nenhuma orientação sobre como fazer o seu acesso modelo / dados e na maioria das amostras e tutoriais para ASP.NET MVC não são de produção digna implementações modelo, mas amostras realmente apenas mínimos.

Parece que você está no caminho certo, continue.

No final, você está usando o Entity Framework principalmente como um gerador de código que não está gerando código muito útil e por isso você pode querer olhar para outros geradores de código ou ferramentas ou estruturas que correspondem mais de perto suas necessidades.