Web Service .NET meilleures pratiques pour plusieurs développeurs

voix
1

Nous avons un grand projet ASP.NET composé de plusieurs centaines de rapports. Nous sommes en train de déplacer toutes les requêtes SQL (en cours d'exécution contre une base de données Oracle) en trois services web. Les services Web sont classés par commande, des sélections et des requêtes de rapport. Nous devons déployer un sous-ensemble de notre projet à l'aide d'un back-end SQL * Server à plusieurs endroits qui sont déconnectés de l'Internet. Par conséquent, ayant toutes les connexions à la base de données et des requêtes dans les services Web rend l'application facile à gérer et nous pouvons tirer le sous-ensemble de rapports et ne pas avoir à modifier le code. Le projet est sous contrôle de code source en utilisant le logiciel Serena ChangeMan.

Le problème est que nous avons plusieurs programmeurs et ils ont tous besoin de vérifier les fichiers de services Web pour travailler sur leurs articles. Nous avons mis en œuvre juste ramification, mais il devient peu à peu un cauchemar. Nous avons des livraisons mensuelles de production et parfois objets qui sont censés entrer dans la construction mensuelle se est tenue jusqu'au mois prochain. La fusion est devenue un processus manuel.

J'ai effectuer des recherches sur Internet et je suis surpris que je ne l'ai pas été en mesure de trouver de bonnes « meilleures pratiques » l'architecture de services Web pages blanches. Il y a beaucoup de grandes entreprises qui doivent ont dû faire face à ces problèmes.

Est-ce que la plupart des grands groupes de développement utilisent de branchement? Je l'ai lu que Visual Studio Team System Database Edition pourrait fournir le code standard qui permettra à l'application de se connecter à différentes bases de données. Est-ce que l'achat Team System est la meilleure méthode? Ou est-ce que quelqu'un sait où je peux trouver de la documentation qui nous aidera à répondre à ces questions?

Merci, Lorie

Créé 09/12/2008 à 19:20
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
0

Nous utilisons SOA, mais nous utilisons SVN qui est plus orienté la fusion. Peut-être envisager un système de contrôle de source différente?

Créé 09/12/2008 à 19:27
source utilisateur

voix
2

Ce problème semble être tout à fait indépendante de l'objet du logiciel. La question ici est que vous avez un petit nombre fini de fichiers que plusieurs développeurs vont travailler sur une base quotidienne. Je n'ai pas d' expérience avec le logiciel Serena ChangeMan ni TFS autres que de jouer avec elle. J'ai l' expérience avec deux systèmes de contrôle de version qui utilisent un modèle de fusion / commit: CVS et Subversion . Ce sont deux excellents systèmes de contrôle de version gratuite qui sont largement utilisés.

Si vous n'êtes pas familier avec le modèle de fusion / commit, l'idée est ici qu'aucun développeur unique ne peut « caisse » et verrouiller un fichier pour les changements. Tout le monde peut télécharger et apporter des modifications à tout fichier. Quand il est temps de valider ces modifications dans la base de données de code source, le logiciel de dépôt empêchera un commit si d'autres modifications ont été apportées au dossier par un autre développeur. La nouvelle version est ensuite téléchargée, et dans la plupart des cas, les changements sont automatiquement fusionnés avec vos changements. Vous êtes-test, puis vous vous engagez cette version. Ce modèle est très réussi et très évolutive.

Ayant dit tout cela, même le modèle de fusion / commit ne peut pas résoudre la douleur d'avoir un petit nombre de fichiers avec beaucoup de développeurs d'apporter des modifications auxdits fichiers. Je recommande diviser vos fonctionnalités en plus de services web. Peut-être au lieu de trois, les services Web monolithique vous pouvez créer trois groupes de services Web connexes. Je pense que cela, couplé à l'aide d'un système de contrôle de version avec fusion / commettras résoudra vos problèmes.

serveurs CVS et Subversion fonctionnent sous Windows, Mac et Linux. Il y a un certain nombre de clients pour chacun, disponible sur un certain nombre de systèmes d'exploitation. Ceux-ci comprennent les clients, stand-le long plugins Visual Studio et plugins shell. Un autre avantage est que les deux CVS et Subversion sont disponibles à partir de la ligne de commande qui rend les scripts (pensez génération automatisée) assez facile.

Créé 09/12/2008 à 19:34
source utilisateur

voix
1

Pourquoi ne pas segmenter votre logique dans les fichiers de classe individuels qui peuvent être vérifiés par chaque développeur?

Créé 09/12/2008 à 22:05
source utilisateur

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