maneira correta de desenvolver um aplicativo grande

Question

Estamos desenvolvendo um aplicativo muito grande web em .Net 3.5. Dois vendedores independentes estão envolvidos com experiência em diferentes áreas. Ambos os fornecedores estão localizados remotamente e trabalhar em área funcional separada do mesmo aplicativo web. Eu queria saber qual é a melhor maneira de lidar com o desenvolvimento da interface do usuário.

A interface do usuário tem uma estrutura principal, onde do lado esquerdo e lado superior tem links de navegação. Ao clicar em um link abre uma página na área principal. As páginas individuais serão desenvolvidos por cada fornecedor. Todo o mestre pode ser desenvolvido por um fornecedor. No mestre de layout Eu uso iframe para mostrar a página individual na área principal.

I implantar o aplicativo mestre em uma piscina de IIS-Master, Um aplicativo vendedor em uma piscina de IIS-A e aplicativo fornecedor B em uma piscina de IIS-B. A piscina do IIS para fazer o balanceamento de carga como o número de usuários são altas.

Além disso, este aplicativo web é baseada no acesso, ou seja, necessidade do usuário fazer o login para acessar as páginas. Eu entendo Eu preciso implementar single sign-on, bem aqui como locais diferentes estão envolvidos.

Esta é uma boa ideia? Existe alguma alternativa?

---

EDIT APÓS RESPOSTAS

Eu também tenho a mesma apreensão como mencionado em suas respostas. Mas a solução que eu tenho em mente é não só porque dois vendedores estão envolvidos. Os dois fornecedores estão envolvidos porque duas áreas funcionais separadas estão lá e ambas as áreas têm sua própria carga de usuário para que ele ajuda na balanceamento de carga corretamente também. Eu estava pensando em criar completamente dois sites com single sign-on implementado. Mas a questão é a manutenção da parte comum de UI. biblioteca comum é fácil como pode ser desenvolvido por um fornecedor e distribuir a DLL para outro fornecedor. Como podemos fazer isso para a camada de interface do usuário?

Answer 1

Como trabalhar com equipes distribuídas pode ser difícil - especialmente em aplicações maiores. Na verdade, às vezes desnecessariamente mudar nossa arquitetura simplesmente porque nós pensamos que fará o ciclo de vida de desenvolvimento mais fácil.

Eu pessoalmente acredito que os fundamentos de software como controle de versão, integração contínua, revisões de código e escalas de comunicação aberta muito bem. Sugiro pensar deste projeto como uma aplicação única, que passa a ser codificado por várias equipes de desenvolvimento. Faça alguém (s) responsável pela integração de código, certifique-se que todas as equipes estão na mesma página e não mudam sua arquitetura para atender às suas dinâmica da equipe.

A pergunta que você tem a fazer é: você está realmente melhor fora desnecessariamente manutenção de vários sites e um único sistema de início de sessão ou você está apenas sugerindo esta abordagem, porque você acha que isolar os fornecedores e mantê-los focados em seu core área (s) de a aplicação é a abordagem correta?

Answer 2

A minha primeira impressão sobre o que você escreveu é que pode valer a pena re-considerar a arquitetura.

Com iframe que você vai correr em muitas questões, o primeiro é o comportamento do botão do navegador de volta.

Uma alternativa possível seria usar comunicação remota ou serviços da Web entre o aplicativo principal e A e B e lidar com toda a interface de usuário em um só lugar. Pode ser muito difícil de coordenar o desenvolvimento de uma interface de usuário consistente com dois fornecedores diferentes.

Answer 3

Por que não trabalho, tanto da parte do desenvolvimento no mesmo projeto UI, contanto que eles estão compartilhando a mesma instância de um ramo de controle de origem. Quando os masterpages são desenvolvidos, que podem ambas as páginas cliente a construir contra o modelo mestre sem incomodando a outra parte?