.NET Web Service Best Practice para vários desenvolvedores

votos
1

Temos um projeto ASP.NET grande que consiste de várias centenas de relatórios. Estamos no processo de mover todas as consultas SQL (que funcionam contra um banco de dados Oracle) em três serviços da web. Os serviços web são categorizados por comando, seleções e consultas de relatório. Nós temos que implantar um sub-conjunto de nosso projeto usando um SQL * backend Server para vários locais que estão desconectados da Internet. Portanto, ter todas as conexões com o banco de dados e consultas nos serviços web torna o aplicativo gerenciável e podemos puxar o sub-conjunto de relatórios e não tem que modificar o código. O projeto está sob controle de origem usando software Serena ChangeMan.

A questão é que temos vários programadores e todos eles precisam verificar os arquivos de serviços da Web para trabalhar em seus itens. Acabamos implementado ramificação, mas está lentamente se tornando um pesadelo. Temos entregas mensais de produção e, por vezes, itens que são supostamente para ir para o acúmulo mensal se levantou até o próximo mês. A fusão tornou-se um processo manual.

Eu tenho conduta Internet Pesquisas e eu estou surpreso que eu não tenho sido capaz de encontrar qualquer boas páginas brancas arquitetura “melhor prática” serviços web. Há muitas grandes empresas que deve ter enfrentado essas questões.

Não mais grandes grupos de desenvolvimento usam ramificação? Eu li que o Visual Studio Team System Database Edition poderia fornecer o código padrão que irá permitir que o aplicativo se conecte a diferentes bases de dados. Será que compra Team System ser o melhor método? Ou alguém sabe onde eu posso encontrar documentação que vai nos ajudar a resolver estas questões?

Obrigado, Lorie

Publicado 09/12/2008 em 19:20
fonte usuário
Em outras línguas...                            


3 respostas

votos
2

Este problema parece ser bastante independente do propósito do software. A questão aqui é que você tem um número pequeno, finito de arquivos que vários desenvolvedores estará trabalhando com em uma base diária. Eu não tenho experiência com software Serena ChangeMan nem que não brincar com ele TFS. Eu tenho experiência com um par de sistemas de controle de versão que usam uma mesclagem de modelo / commit: CVS e Subversion . Estes são ambos excelentes sistemas de controle de versão, livres que são amplamente utilizados.

Se você não estiver familiarizado com a fusão modelo / commit, a idéia aqui é que nenhum desenvolvedor pode "check-out" e bloquear um arquivo para mudanças. Todos podem baixar e fazer alterações em qualquer arquivo. Quando é hora de cometer essas alterações para o banco de dados de código-fonte, o software repositório irá impedir um commit se outras mudanças foram feitas para o arquivo por outro desenvolvedor. A nova versão será baixada, e na maioria dos casos, as alterações são automaticamente fundiu-se com as alterações. Você re-teste, e depois de se comprometer essa versão. Este modelo é muito bem sucedido e muito escalável.

Dito tudo isso, até mesmo a fusão / commit modelo não pode resolver a dor de ter um pequeno número de arquivos com um monte de desenvolvedores que fazem alterações ao referido arquivos. Eu recomendaria dividir sua funcionalidade em mais serviços web. Talvez em vez de três, serviços web monolíticas que você pode criar três grupos de serviços web relacionados. Eu acho que isso, juntamente com o uso de um sistema de controle de versão com merge / commit vai resolver seus problemas.

servidores CVS e Subversion executado em Windows, Mac e Linux. Há um número de clientes para cada um, disponível em um número de sistemas operacionais. Estes incluem destacam-along clientes, plugins Visual Studio e plugins de fachada. Outra vantagem é que ambos CVS e Subversion estão disponíveis a partir da linha de comando que faz scripting (pense compilação automatizada) bastante fácil.

Respondeu 09/12/2008 em 19:34
fonte usuário

votos
1

Por que não segmentar a sua lógica em arquivos de classe individuais que podem ser verificados por cada desenvolvedor?

Respondeu 09/12/2008 em 22:05
fonte usuário

votos
0

Usamos SOA, mas também usamos SVN, que está se fundindo mais orientada. Talvez considere um sistema de controle de origem diferente?

Respondeu 09/12/2008 em 19:27
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more