Devo separar a parte administrativa do resto da guerra?

5

Eu construí um web-applicationg usando struts2. Então eu construí uma pequena interface de administração na mesma guerra.

Com o tempo, o webapp cresceu e, portanto, a interface administrativa. Agora, estou pensando em separar a interface de administração do restante do aplicativo em uma guerra separada

É uma boa ideia? Existe algum benefício de desempenho que eu possa obter devido à separação entre a guerra do administrador e o resto da webapp.

A parte administrativa é principalmente sobre como fazer alterações / updations / settings no banco de dados, por isso não está afetando diretamente a interface do usuário do restante do aplicativo. Separá-lo também garante que eu possa fazer updations para ambas as partes sem afetar o outro.

[ATUALIZAÇÃO]

Não consigo colocar a administração na máquina local. É um aplicativo da web.

Do they use the same classes? Não, o pacote inteiro é diferente para ações administrativas e a visualização também é separada.

How do you update them? carregar guerra

Do you use application session? sim, claro, embora sessões diferentes sejam usadas para admin & usuário normal.

    
por coding_idiot 30.09.2013 / 13:36
fonte

1 resposta

3

Separar diferentes partes de um aplicativo da Web umas das outras como guerras separadas significa que é possível parar e reiniciar aplicativos individuais no servidor de aplicativos e, possivelmente, simplifica o controle de acesso em cada aplicativo. As aplicações separadas significam que, em teoria , é possível implementar mudanças no administrador (retirá-lo da linha, reimplementá-lo) enquanto o aplicativo principal ainda está em execução (note que a teoria é enfatizada - mais sobre isso adiante) .

Isso é realmente para benefícios. Pode-se ver algum pequeno aumento de desempenho nas páginas de administração devido a um número reduzido de sessões lá. É improvável que se veja algum desempenho melhorado na aplicação principal.

Agora, as implicações tornam isso muito mais desafiador e eliminam alguns dos possíveis ganhos.

Considere se você tiver um objeto user . Isso tem métodos como changePassword que podem ser feitos pelo administrador ou pelo usuário.

Considere estas duas opções:

  • você está usando o hibernate ou algum outro orm para anotar a tabela do usuário para o objeto do usuário
  • você tem uma camada de acesso a dados que executa consultas nativas no banco de dados

Você novamente tem duas opções para isso:

  • duas cópias da camada de objeto / dados do usuário - uma em cada guerra
  • um frasco externo que as duas guerras carregam

Sempre que você fizer uma alteração de esquema (qualquer coisa que precise atualizar o usuário ou a camada de dados), você terá pelo menos o dobro de trabalho (recarregue os aplicativos e para garantir que eles fiquem sincronizados) , ou você terá que recarregar o jar compartilhado e reiniciar os dois aplicativos (e se o servidor do aplicativo estiver sendo muito exigente, reinicie-o).

No final do dia, você descobrirá que copiou todo o conjunto de objetos de dados (e camada de dados). O administrador pode ter mais alguns, mas provavelmente tudo o que está no aplicativo principal estará no admin.

Existe um dano real nos bugs se os dois duplicarem os dados / modelo. Além disso, você se verá duplicando as visualizações (a visualização do administrador de uma página de atualização do usuário versus a visualização principal do aplicativo de uma página de atualização do usuário).

Por fim, você provavelmente descobrirá que há apenas pequenas diferenças na autorização entre os dois aplicativos: você deseja compartilhar a mesma autenticação, os mesmos dados e, provavelmente, as mesmas visualizações. Eles são apenas controladores diferentes para administração e usuário normal.

A partir disso, provavelmente é melhor manter tudo como um aplicativo. Não se repita. Não duplique as visualizações e não duplique os modelos.

    
por 30.09.2013 / 16:26
fonte