|
gortogg |
  |
Confirmé
Déconnecté
Niveau : 3
N° de Membre :
6145
Ancienneté : 98%
Participation : 2%
Inscription: 16 Nov 2002
Localisation: Freux ou Bominable, ça dépend des jours
Age: 45
Messages: 1320
Sujets Lancés : 38
|
Le Framework .Net a été conçu pour répondre aux objectifs suivants :
• Fournir un environnement de programmation orienté objet pour des applications dont le code source peut être stocké et exécuté localement, exécuté localement mais stocké sur Internet, ou exécuté à distance.
• Fournir un environnement d'exécution qui facilite le déploiement des applications et les conflits de versions.
• Fournir un environnement d'exécution garantissant l'exécution sécurisée du code source, même pour du code créé par des développeurs externes.
• Fournir un environnement d'exécution qui élimine les problèmes de performances liés aux environnements de scripts ou interprétés.
• Rendre l'expérience des développeurs conforme au développement d'applications variées, telles que les applications Windows classiques mais aussi les applications Web.
• Construire toutes les communications sur les standards de l'industrie pour s'assurer que le code basé sur le Framework .Net puisse être intégré à tous les autres codes sources.
C'est une grosse usine à gaz qui est vertainement très pratique pour des entreprises du même niveau "d'usine à gaz" (je me suis occupé du développement d'un logiciel galère de retour d'espérience et gestion de risques financiers pour mon TFE, on attendait impatiamment un outil de ce style qui nous aurait simplifié la vie pour "développer" nos outils de gestion, mais ce n'est pas ce que j'appelle du développement)
Il fallait plutôt entendre recherche....
Maintenant que j'y pense, il y a aussi des inconvénients en gestion pour une banque de données:
• Toutes les règles métier sont contenues dans le code frontal. En conséquence, s'il vous faut modifier une règle métier, tous les clients doivent être mis à jour. Si vous n'avez pas de système automatisé de mise à jour, cette tâche de maintenance peut s'avérer cauchemardesque. Bien sûr, si vous utilisez SQL Server, vous pouvez mettre certaines règles métier dans les procédures stockées pour diminuer le temps et les coûts de maintenance. -> si tu n'as pas une usine à gaz déjà en place, c'est le bordel, ou t'es obligé d'en créer une
• Tous les noms de champ sont codés en dur soit dans le code source, soit dans les propriétés des contrôles. Si vous changez un nom de champ, vous devez rechercher et remplacer toutes les occurrences dans votre application. Si vous utilisez la liaison de données, vous devez aussi vérifier tous les formulaires et modifier les propriétés. -> Pas chiant du tout....
• Le transfert de données entre deux composants via un réseau est plus lent que la connexion directe à la base de données. Dans un scénario intranet, .NET Remoting peut s'avérer plus performant qu'un service Web Services. Vous serez moins amené à utiliser .NET Remoting dans un scénario Internet. -> Nickel pour les entreprises (beaucoup d'intranet, pour le reste y compris tout le HTTP... c'est pas la joie)
Bien sur, ces inconvénients ne tiennent pas le coup si on utilise un serveur SQL au lieu d'une banque de données
Cela convient-il comme analyse au sieur Didou?
__________________
"Si tu peux te quoter toi même, t'es trop fort" Gortogg
Edité par gortogg le 01-03-2005 à 08:22
Signaler ce message à un modérateur | IP: Logguée
Temps en ligne : 24 Jours, 18 Heures, 13 Minutes, 7 Secondes en ligne
|
01-03-2005 06:53
), du Perl (!), du Java (JSP, Servlet...), de l'ASP, du Coldfusion, du PHP
.
