Aplicativos Web – combinar ou separar?

Question

Para a nossa empresa, estou criando um grande site de extranet que contará com um conjunto de subaplicativos.Estou um pouco confuso sobre qual deveria ser a configuração correta da solução e dos projetos.

Tenho uma aplicação web que chamamos de Portal.Ele contém as classes de autenticação/autorização, masterpages, classes de navegação/roteamento de URL e definições de tema.Ele também conterá algumas visões gerais básicas para que nossos clientes tenham uma ideia rápida do status de seus projetos.

No próximo ano iremos desenvolver e integrar mais aplicações ao portal.Pense nisso como visões gerais detalhadas e ferramentas chamadas Recurso A, B e C.Com o passar dos anos melhoraremos esses aplicativos e lançaremos novas versões.Estas aplicações web devem enquadrar-se perfeitamente na navegação do Portal.Gostaria que eles reutilizassem as masterpages e os temas.

Qual é a maneira correta de configurar esta solução?
Como posso unir os aplicativos, reutilizar as páginas mestras e mantê-las fáceis de manter?
Como posso compartilhar certos webcontrols (ASCX) de maneira adequada?
Estamos usando o TFS, talvez alguma ideia de ramificação/fusão?

Editar:
Gostaria de criá-lo em ASP.Net WebForms, temos mais experiência nessa área.Mas basicamente podemos usar qualquer coisa, temos o servidor web sob nosso próprio controle (desde que seja orientado para Microsoft, não mudando para php ou algo parecido :))

Answer 1

What is the proper way to setup this solution?

Da maneira correta ... existem tantos. Eu já vi muitas aplicações, e muitas diferente Configurações (muitas das quais eu consideraria "apropriado"). O que você realmente está pedindo é a melhor maneira de sua situação.

Como você está construindo um portal, você terá o luxo de separação de recursos que o ajudará ao desenvolver recursos adicionais para o seu aplicativo.

Eu configuraria um único site com uma pasta separada para cada recurso. Tornando -o um único site permitirá que todos os recursos compartilhem as mesmas páginas -masters, userControls e arquivo de configuração - sem ter que fazer nada de especial. (Nessa nota, eu colocava todas as suas páginas mestras em uma pasta sozinha e criava outra pasta para seus userControls).

How can I tie the applications together, re-use the master pages and keep it maintainable?

Novamente ... as pastas são a melhor opção aqui. As pastas ajudarão a separar cada recurso, facilitando o gerenciamento do aplicativo.

How can I share certain webcontrols (ASCX) in a proper way?

Primeiro de tudo, os arquivos ASCX não são WebControls. Eles são UserControls. O WebControl é uma classe para criar controles de servidor que residem em um conjunto separado. Em relação ao UserControls, como eu disse acima, se você os colocar em uma pasta separada, eles estão sempre em um só lugar e estão disponíveis durante todo o aplicativo.

We are using TFS, perhaps any branching/merging ideas?

Realmente não há nada de especial que você precise fazer aqui. Existem muitos caminhos diferentes que você pode seguir em relação à ramificação:

• Um é criar um ramo para cada lançamento.
• Outra é criar uma ramificação para cada novo recurso que você adicionar (no seu caso, isso é praticamente o mesmo que a primeira opção).
• Outro é criar uma filial para cada desenvolvedor.

Quando decidir como vou ramificar meu código, penso no que mais me protegerá. No seu caso, você precisa planejar as correções de bugs entre as liberações de recursos, para que talvez uma ramificação após cada versão faça mais sentido (chame de sua filial dev). Dada a separação de recursos, porém, um recurso pode não afetar o restante do aplicativo. Você pode não precisar desse tipo de ramificação para ser seguro.

Answer 2

Como Brian diz ao fazer um público da API, você deve se comprometer com ele o máximo possível, o que significa que ele deve mudar o mínimo possível após o lançamento inicial. No entanto, para fazer algo que estável requer muito esforço, por isso, se você não estiver pronto para se comprometer com a API, você deve internalizá -la o máximo possível e, por esse motivo, poderá combinar as coisas mais do que separá -las.

No entanto, não vou sugerir uma arquitetura que se encaixe no seu aplicativo com base em uma descrição de 5 parágrafos. O que você precisa fazer é ponderar os prós e os contras de ter alguns grandes projetos versus ter um monte de pequenos projetos pouco acoplados. Quero dizer, quanto mais planejamento você fizer antecipadamente, mais fácil você o terá na linha, desde que fique com o plano.

Então, ao contrário de Brians, responde, eu não recomendaria que você faça todo o seu sistema "o mais vagamente acoplado possível", apenas que você o torna tão livremente acoplado possível. ;) O código pouco acoplado pode causar tantos problemas quanto o código fortemente acoplado, se você estiver abusando.

Ver:
1. O que é melhor, muitas pequenas montagens ou uma grande montagem?
2. Lado de baixo específico para muitos membros de Mumal '?

No final, somente você sabe quanto deseja se concentrar em cada uma das "... BILIidades", manutenção, extensibilidade, confiabilidade etc. Portanto, obtenha suas prioridades e objetivos diretamente e planeje de acordo.

Sobre estratégias de ramificação, você poderia ler o Diretriz de ramificação TFS 2.0 que têm uma boa introdução a várias estratégias de ramificação que variam de básico ao avançado. Mesmo se você não usar o TFS, este é um bom guia para ler (eu uso o SVN no momento). Como atualmente trabalho em equipes pequenas com 1-4 desenvolvedores, costumo usar uma estratégia entre básico e padrão. Não que eu esteja recomendando isso para você, mas o que funciona melhor para a nossa equipe.

Quanto ao compartilhamento de código entre projetos. Em svn que podemos usar "externo"O que significa que o arquivo compartilhado aparecerá em várias pastas; portanto, quando você alterar uma cópia e confirmar a alteração para o SVN, todas as outras cópias serão atualizadas na próxima atualização do SVN. No entanto, não me lembro se o TFS tem algo semelhante .

Observação: Cuidado com os externos no SVN ... eles podem causar ... problemas. ;)

Meu conselho é tentar evitar o compartilhamento de páginas ASPX, ASCX e Master o máximo possível. Geralmente dói muito mais do que ajuda. Em vez disso, tente usar herança ou outras alternativas para atingir seu objetivo.

O ASP.NET MVC 2.0 possui um conceito chamado "áreas", onde você constrói subseções de um aplicativo isoladamente do restante. Tanto quanto eu sei, essas áreas podem ser mantidas em projetos separados do aplicativo "principal". Parece muito o que você está solicitando, então talvez você deva analisar isso.

Espero que faça sentido. ;)

Answer 3

Eu consideraria tornar seu sistema como fracamente acoplada que possível.À medida que você adiciona mais aplicativos, seu site se tornará cada vez menos confiável (já que nenhum componente estará ativo 100% do tempo, combiná-los reduzirá sua confiabilidade geral).Portanto, você deve construir seu sistema para atender aos serviços não importantes que estão inativos (acredito que a página inicial da Amazon, por exemplo, tem cerca de 100 serviços contribuindo para isso e, como tal, foi construída para ser tolerante a falhas)

Suas APIs entre serviços devem permanecer tão estáveis ​​quanto possível, de modo que as implementações possam mudar sem quebrar o acoplamento.Você também deve investigar testes automatizados disso no nível da web (talvez Selênio ou similar?) já que testar os serviços individuais lhe dará pouca cobertura sobre o comportamento geral.

Answer 4

Você pode achar útil olhar para a implementação de um costume VirtualPathProvider. No meu último projeto, tivemos vários sites ASP.NET que precisavam compartilhar arquivos de temas (páginas mestres, controles de usuário, imagens, folhas de estilo), então criei um VirtualPathProvider que nos permitiu mapear uma pasta virtual (por exemplo, /temas) para qualquer físico físico Pasta no disco rígido (por exemplo, c: shared sitethemes).

Não é trivial, mas não demorou muito e não causou nenhum problema. Aliás, acabou sendo uma ótima maneira de superar o limite máximo de componentes no WIX ... Observe que você não pode pré -compilar sites que usam um VirtualPathProvider.

Answer 5

Use conceitos de MVC a partir de agora. Eles oferecem mais extensibilidade e flexibilidade para aplicações robustas.

Answer 6

Você pode olhar usando o SharePoint. É uma plataforma bastante decente para a entrega de aplicativos ASP.NET, principalmente se eles coexistirem em um ambiente de intranet; Isso lhe dá muitas coisas de graça.

Obviamente, ele tem cotovelos muito ásperos, por assim dizer, então prossiga com cautela.

Answer 7

Eu não pensaria nos aplicativos como separados, mas como módulos do portal geral.

Eu recomendaria que você olhasse para o MEF, pois isso parece ser um ajuste perfeito.

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx