Qual é a abordagem correta para passar dados de vários modelos para um serviço?

5

Eu tenho um AccountModel e uma página onde o usuário pode fazer upload de um arquivo. O que eu gostaria de ter acontecido é quando o usuário envia o arquivo. O PageController faz algo como o seguinte. esta é uma tentativa rápida, escrita apenas na pergunta para ilustrar minha pergunta.

public class PageController : Controller {
  private Service service;
      public ActionResult Upload(HttpPostedFileBase f){
         service.savefile(f,_AccountModel_whatever.currentlyloggedinuser.taxid)          }
}


public class Service
{
// abunch of validation and error checking to make sure the file is good to store
}

Esta abordagem não estaria em más práticas? Desde que eu estou fazendo meu controlador dependente da existência do AccountModel? Este será um programa ENORME ao longo dos próximos anos, e eu realmente quero maximizar a qualidade do framework agora.

    
por MVCylon 24.05.2011 / 18:30
fonte

4 respostas

1

Par de ângulos aqui. Primeiro, você provavelmente poderia passar o modelo de conta para o seu serviço como uma dependência do construtor se ele fosse de fato usado em todos os lugares. Usando qualquer estrutura do IoC, você pode facilmente se livrar dessas dependências do framework, presumindo que ele as hidrata.

Em segundo lugar, eu normalmente evito usar meu próprio modelo de conta - ou, pelo menos, escrever código nele. Na maioria dos casos, IPrincipal e IIdentity fazem o trabalho para você e tornam o seu modelo de conta muito flexível.

    
por 23.08.2011 / 13:07
fonte
0

É uma prática ruim se houver um caso em que alguém possa passar para o upload de um arquivo sem estar conectado . Nesse caso, haveria uma exceção. Mas você não gostaria que houvesse um? Suponho que você esteja acompanhando os arquivos com base na conta, então você teria problemas de outra forma.

Desde que você tenha certeza de expulsar as pessoas com as sessões expiradas de volta para a tela de login, não vejo nenhum problema além daqueles inerentes aos aplicativos da web não com estado.

    
por 24.05.2011 / 18:58
fonte
0

Você pode abstrair o modelo da conta com uma interface compartilhada com o controlador, se estiver preocupado com alterações no AccountModel. Mas IMO, os modelos "geralmente" não mudam com o tempo (Eles podem aumentar de forma incremental) por causa da dependência usual do armazenamento abaixo - a migração de dados em um sistema de produção é uma dor. Então você pode estar se preocupando prematuramente neste caso.

Você não quer um sistema com uma interface para cada interação com o modelo. Tente identificar as partes fluidas e abstrai-as sozinhas. Uma boa visão do produto a longo prazo deve ajudá-lo a chegar aos blocos de construção certos em primeiro lugar.

    
por 25.05.2011 / 11:55
fonte
0

O seu AccountModel é o principal de algum tipo? Se assim for, eu realmente me certificaria de implementar o IPrincipal e seguir os padrões normais. Você pode então puxar o diretor para dentro e lançá-lo para obter os dados que você precisa.

Se não, você pode ter um AccountModelId em um campo de formulário oculto. Faça seu método de ação usar um AccountModel. Um fichário de modelo personalizado pode procurar por esse id e recuperar seu modelo para você, se ele precisar ser lido de um banco de dados ou algo assim.

De qualquer forma, você está em um bom local para poder testar seu controlador como o mock de AccountModel é facilmente dado ao controlador.

    
por 22.10.2011 / 14:55
fonte

Tags