O que devo considerar ao decidir se devo usar um backend de serviço da Web em vez do MVC tradicional?

Question

O que devo considerar ao decidir se devo usar um backend de serviço da Web em vez do MVC tradicional?

#1 resposta do (5 votos)
#2 resposta do (1 votos)
#3 resposta do (0 votos)

5

Estamos tentando decidir qual arquitetura será usada em um aplicativo da web que eventualmente terá uma parte móvel também. O núcleo do projeto é um aplicativo da Web de rede social, e a parte móvel provavelmente terá um subconjunto limitado da funcionalidade da Web.

As duas opções que estamos analisando são um back-end de serviço da web completo ou uma estrutura MVC tradicional para o aplicativo da web e o desenvolvimento de serviços da web no lado para o aplicativo móvel mais tarde.

Alguns argumentos para a rota somente de serviço da Web é que ela seria "mais simples", já que teríamos que criar um serviço da Web em vez de criar um serviço da Web para a parte móvel e funções / chamadas adicionais do banco de dados para o aplicativo da web. Usando esse método, o aplicativo da Web buscará dados dos serviços da Web usando javascript, o que geraria a página html (soa como o que uma estrutura tradicional de MVC faz, mas dessa forma exigiria que tudo fosse feito em javascript). / p>

Não estou me sentindo bem com a ideia de usar os serviços da Web apenas porque não faz sentido para mim, mas estou tendo problemas para esclarecer meus problemas com isso.

Então, o que devo considerar ao tentar determinar se devemos usar um back-end de serviço da Web completo para o nosso projeto, em vez de MVC tradicional com serviços da Web disponíveis apenas quando necessário para a parte móvel do aplicativo?

Estou à procura de uma resposta abrangente para esta pergunta, não muitas respostas contendo uma única parte da resposta.

programming-practices web-development

por kurisu 12.05.2012 / 04:45

fonte

3 respostas

Tags programming-practices web-development

Quando devo iniciar a codificação do lado do servidor? Diferença entre o planejamento de um projeto e o planejamento de um produto

score 5 · Answer 1

Quando implementado corretamente, você poderá ter os dois mundos. Quando você vai a rota do serviço da Web você pode estar enviando a versão json dos modelos que você estaria usando para renderizar suas visualizações MVC com o contrário.

Para a versão web, você precisa construir seu html em algum lugar. Eu acho que você pode fazer isso principalmente do lado do servidor ou fazê-lo usando alguma forma de modelos lado do cliente javascript. O dado / modelo requer que seja o mesmo.

Se a rota de serviço da web significa SOAP, eu discordaria também.

Por que não tornar o aplicativo da web móvel? Você pode acabar não precisando de um aplicativo nativo para dispositivos móveis ...

score 1 · Answer 2

Parece que a abordagem típica do MVC é usar exatamente um modelo, um controlador e um modo de exibição todos vinculados especificamente a um determinado tipo de página.

Mas o objetivo de separar essas preocupações é resolver problemas exatamente como este. Você deve ser capaz de ter um modelo e um controlador que operam em duas visualizações diferentes, sua exibição móvel e sua visualização de aplicativo da web. Ou pelo menos um modelo compartilhado.

O serviço web requer que você tenha back-end devs capaz de entregar dados em um formato fácil de analisar para desenvolvedores front-end que saibam manipular strings, dados e manipulação de DOM, mas se não o fizerem tenho experiência nisso, não tenho certeza se confiaria neles para saber que será mais fácil. Eu ficaria um pouco desconfiado porque coloca toda a carga de estrutura e organização no front end, que as pessoas tendem a ser ruins em estruturar e organizar. Se é um aplicativo bastante simples, parece razoável para mim.

score 0 · Answer 3

Os fatores que levariam a uma interface de serviço unificada incluem um modelo de dados complexo, necessidade de impor regras comerciais ou de segurança de forma consistente, encapsular modelos de dados de ciclos longos de atualização ou ter muitos tipos diferentes de aplicativos clientes compartilhando dados. O limite de serviços da Web também pode ser um limite organizacional útil em equipes maiores - faça com que alguns desenvolvedores se concentrem na API, enquanto outros criam aplicativos sobre ela.

No seu caso, acho que o híbrido seria a melhor escolha. Parece que a maioria dos recursos estará no site, e seria um trabalho extra construir o site sobre uma API criada principalmente para o aplicativo da Web.

Como ponto de esclarecimento, você pode usar o MVC com serviços da web. No cliente, você gravaria objetos de acesso a dados que falariam com o serviço da Web e, em seguida, criaria controladores sobre eles para gerenciar a interface do usuário. No lado da API, as interfaces de serviço da web se beneficiam da aplicação do MVC. Você poderia suportar vários protocolos usando modos de exibição alternativos - como JSON, SOAP, RMI, Avro - ao compartilhar um modelo comum.