Onde devo colocar uma solicitação de API no MVC?

Estou construindo um aplicativo Web usando um padrão MVC. Seguindo esse tipo de arquitetura, podemos ver que todos os métodos usados ​​para interagir com o banco de dados são implementados no modelo .

Mas o que acontece se eu precisar chamar um serviço exposto por outras pessoas na web? Por exemplo, eu gostaria de acessar a API do Facebook para obter todos os seguidores da minha página, então, onde coloco esses métodos?

Obviamente, a visualização não é uma boa ideia, porque este módulo é dedicado à apresentação, o controlador não deve ser usado para recuperar dados, mas o modelo geralmente é dedicado apenas à interação com o banco de dados.

Então, você pode me dar uma dica sobre isso? E por favor, você pode me dizer se estou cometendo alguns erros sobre a arquitetura MVC?

O modelo não se limita à interação com o banco de dados, ele é responsável por obter e manipular dados.

Portanto, para sua visão e controle, não deve fazer diferença, se os dados vierem de um banco de dados ou de um serviço da web ou forem totalmente aleatórios, portanto, você deve fazê-lo no modelo.

MVC é um padrão de apresentação que separa apenas as diferentes camadas de representação.

Isso não significa que esse modelo deva ser uma bagunça uniforme do código do espaguete. Seu próprio modelo também pode ser em camadas, mas o controlador não deve saber de onde vêm os dados.

Um método público em seu modelo pode ser estruturado desta forma (pseudo-código), que pode ser chamado pelo seu controlador:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServicee ORMpode haver instâncias de interfaces que podem ser substituídas por zombarias por injeção de dependência, mas seus controladores e visualizações não precisam ser alterados para fins de teste.

Existe um mal-entendido comum (intencional?) Sobre o que M, V e C são. Não sobre os papéis que eles assumem, mas quais são eles.

Na definição original de MVC da GUI da área de trabalho, eles eram módulos . Normalmente, um aplicativo tinha vários deles, às vezes trabalhando em trigêmeos, às vezes tendo uma variedade de visualizações e modelos que alguns controladores podiam misturar e combinar.

Nos frameworks web, OTOH, eles tendem a ser vistos como camadas , onde são apenas um de cada um e lida principalmente com a cobertura de algum nível de abstração subyacent: "a camada de modelo abstrai o banco de dados", "a camada de visualização implementa a apresentação", "o controlador camada processa a entrada do usuário ".

Então, eu diria que você já tem um modelo, dedicado à interação com o banco de dados, e agora apenas precisa criar outro modelo para lidar com sua API de origem. Se você os tornar o mais semelhante possível, a maior parte do controlador e do código de exibição poderá funcionar perfeitamente com qualquer um dos modelos.

Parte da dificuldade de qualquer discussão sobre o MVC é que diferentes grupos o cooptaram para significar coisas diferentes. A implementação do MVC usada em, por exemplo, um aplicativo Rails, seria quase irreconhecível para alguém que escreve um aplicativo Swing. Na medida em que o MVC ainda é uma coisa bem definida, é mais um conjunto de princípios orientadores (separar o aplicativo principal da sua representação visual, fornecer mecanismos flexíveis para permitir que os dois sejam executados juntos), que podem ser implementados em vários maneiras.

De fato, há uma tendência a atribuir nomes diferentes a diferentes designs derivados do MVC (consulte este artigo de Martin Fowler para uma discussão sobre isso), ou mesmo a desistir de nomes precisos - por exemplo, o AngularJS se descreve como um Model-View-Whatever estrutura.

Portanto, é difícil responder sem saber com qual versão do "MVC" você está trabalhando. No entanto, uma solicitação de API normalmente faria parte do aplicativo principal (a parte que não deve ser alterada se você decidir usar uma representação visual diferente), que em muitas implementações estaria totalmente contida no modelo.

Aqui , o modelo é descrito assim:

Um modelo armazena dados que são recuperados no controlador e exibidos na visualização. Sempre que houver uma alteração nos dados, eles são atualizados pelo controlador.

Eu diria que o controlador inclui a lógica de chamar o serviço ou chama um Serviceobjeto separado . Se o serviço for separado, você poderá criar testes com mais facilidade, por exemplo, se nenhuma conexão com um serviço pela rede for possível, alguns TestServicepoderão fornecer respostas do Servicelocal.

Verifique também esta resposta que sugere que o Controlador chama o serviço.

Seu modelo nunca deve conter nenhum código real e deve ser visto como mais uma mensagem ou uma estrutura usada para gerenciar o conteúdo manipulado pelo controlador e exibido pela visualização.

Seu controlador deve ser responsável por entrar em contato com quaisquer APIs, bancos de dados, serviços, etc ... solicitando uma alteração e gerenciando as atualizações necessárias para o modelo.

Toda a força do padrão MVC é que ele desacopla a lógica (o controlador) da visualização e do estado (o modelo). Ao fazer isso, agora você tem a garantia de que apenas o código no controlador pode criar efeitos colaterais, pois a visualização e o modelo simplesmente não têm permissão para fazer alterações.

Ele também permite uma melhor reutilização de código, pois um modelo pode ser compartilhado entre vários controladores e visualizações.

Pode estar longe daqui, mas é assim que me sinto em relação aos WebApps e ao trabalhar com APIs remotas [complexas] em muitos casos:

Eu o tornaria uma classe (ou seja, uma biblioteca de métodos de mitigação de dados) em vez de modelo (ou seja, pilha de funções de mitigação de dados). Parece que agiria de maneira mais transparente, mais independente de lógica / esquema, e você poderia usá-lo em qualquer lugar sem carregar-> chamando um modelo / controlador sempre que quiser usá-lo. A lógica ainda está separada, o ponto de dados ainda é flexível e parece mais aberto à interoperabilidade em casos estranhos, como empilhar clientAJAX-> appJSON-> appJSON-> appLIB-> remoteAPI-> remoteJSON etc. para pesquisar indiretamente o endpoint.