Les "plug-ins" ASP.NET 2.0 indiquent que
parmi les nouvelles fonctionnalités d'ASP.NET 2.0, les plus "éblouissantes" sont les pages maîtres, les thèmes/skins,
Gestion des adhésions et des rôles, attributs définis par l'utilisateur et personnalisation des pages pour les WebParts.
À l'exception des deux premiers éléments, le reste est basé sur les services fournis par ***Fournisseur.
Ces Fournisseurs (classes) sont généralement définis dans les documents Microsoft comme suit : fournir... des services pour...,
Cela semble être la même chose que les classes de contrôle générales, etc., utilisez-le simplement. En fait, ces Provider (classes)
Cela fait très fortement allusion à une direction de développement de Microsoft .NET.
Cette direction consiste à "plug-in" l'application (votre site Web).
"Plug-in" est emprunté par le petit frère pour expliquer visuellement le problème. Il n'est pas forcément précis et strict et est différent de la notion de "plug-in" dans les documents Microsoft.
Permettez-moi d'expliquer brièvement la raison pour laquelle on l'appelle un « plug-in » du point de vue logiciel et matériel :
D'un point de vue matériel : si vous imaginez un PC, web.config peut-il être considéré comme une « carte mère » ?
Ces fournisseurs sont les cartes graphiques, les cartes son, les cartes réseau... qui sont branchées sur la carte mère. De manière plus abstraite, on peut considérer que ces Providers sont en réalité équivalents à des drivers. Microsoft nous fournit des produits de marque Microsoft
SqlMembershipProvider, SqlRoleProvider, SqlProfileProvider, SqlPersonalizationProvider
Le fournisseur nous permet également de les remplacer en les re-spécifiant dans web.config (équivalent à définir le CMOS ou à faire des "cavaliers").
C'est comme peu importe la marque ou le modèle de carte graphique (ou carte son, carte réseau, etc.), tant qu'elle répond aux normes de compatibilité, elle peut être branchée sur la carte mère pour être utilisée.
Penser d'un point de vue logiciel : depuis le lancement d'Eclips, les « plug-ins » sur la plateforme de développement sont également devenus populaires (ils sont disponibles dans les navigateurs depuis longtemps).
Pendant un certain temps, les programmeurs Java écrivaient des « plug-ins ».
Côté .NET, comme il y a VS.NET, l'impact n'est pas très grand, mais on utilise aussi les "plug-ins".
Je me demande si vous, mes frères, avez remarqué que VSS est intégré à VS.NET sous la forme d'un "plug-in".
Un exemple plus pur est Borland Togather pour .NET. A partir de ces "plug-ins" intégrés dans l'EDI, nous pouvons voir que les "plug-ins" fournissent une sorte d'extension fonctionnelle et de mise à niveau/remplacement. S'appuyant désormais sur ces fournisseurs,
Les programmes de sites Web que nous développons nous-mêmes peuvent également être des « plug-ins ». Par exemple : Si nous n'avons pas besoin de la fonction de personnalisation de page (WebPart), nous n'avons pas besoin d'"installer" PersonalityProvider
(En fait, il faut dire à l'inverse quelles fonctions sont nécessaires pour "installer" quel fournisseur, mais maintenant elles sont toutes préinstallées).
Donc à l'avenir, le développement d'applications sera comme installer des machines sur le marché informatique, il suffit de les assembler et de les installer ?
La réponse est oui : Microsoft a joué avec ainsi en présentant son produit VSTS (Visual Studio Team System).
Vous pouvez assembler un site Web sans écrire une seule ligne de code, et les résultats des tests de performances/stress ne sont pas mauvais (bien sûr, il n’utilise pas que des « plug-ins », il faut probablement l’appeler un composant de toute façon).
C’est vraiment plus MAD que MDA (je plaisante) !
La réponse est également négative : à mon avis, il s'agit en fin de compte d'un produit de laboratoire. Les ingénieurs de Microsoft ont réalisé une « magie » dans des conditions idéales. D'une part, nous ne sommes pas aussi professionnels que les ingénieurs de Microsoft, d'autre part, chaque application. a ses propres limites. Les besoins commerciaux particuliers, pour parler franchement, ne s'appliquent pas nécessairement. De plus, les fournisseurs de la série SQL fournis par Microsoft sont tous implémentés selon une architecture à deux couches, ce qui est difficile à intégrer dans l'architecture multicouche populaire d'aujourd'hui. Pour cette raison, Microsoft a.
http://msdn.microsoft.com/asp.net/downloads/providers/default.aspx?pull=/library/en-us/dnaspp/html/asp2prvdr01.asp
Les exemples de téléchargement de code de ces fournisseurs sont fournis afin que nous puissions les diviser en implémentations multicouches.
à suivre...
http://www.cnblogs.com/windman/archive/2006/09/20/509590.html