Question

Je n'ai pas fait beaucoup de programmation .NET, mais j'ai examiné quelques-uns des blocs d'application publiés par le groupe Patterns and Practices de Microsoft.Je me demandais comment ils sont généralement utilisés :

  • Lié directement aux applications
  • Source ajoutée aux applications et construite avec elles, peut-être avec quelques personnalisations
  • Exemple de code utilisé comme référence lors de l'écriture de code spécifique à l'application

Je suis sûr que ces trois utilisations sont courantes, mais quels sont les modèles d'utilisation les plus courants ?

Existe-t-il quelques blocs d'application particuliers qui sont utilisés par « tout le monde » ?

Note:Cette question est liée, mais pas la même chose, à Blocs d'application de bibliothèque d'entreprise OU framework maison ?.

Était-ce utile?

La solution

Je mets généralement la source dans mon projet, puis je peux obtenir une meilleure intelligence (et une meilleure compréhension de celle-ci).Cependant, je n’ai pas du tout tendance à les personnaliser.J'aime les avoir en stock afin de pouvoir simplement distribuer les binaires en stock chaque fois que j'en ai besoin.

Autres conseils

J'ai beaucoup utilisé la bibliothèque d'entreprise de Microsoft.Ils ne doivent généralement jamais être inclus dans votre projet si possible.Le coût supplémentaire de la compilation peut être lourd.De plus, il n'y a aucune raison d'avoir le code source dans votre projet pour utiliser les classes.Vous obtiendrez toujours des informations pendant le codage tant que vous ajouterez une référence aux DLL dans vos projets.Il est également conseillé d'éviter d'avoir plusieurs bases de code flottantes dans votre environnement de développement.Si vous devez personnaliser les classes, ouvrez-les dans leur propre solution et gardez une version active.Bien sûr, je suggère toujours fortement d'utiliser le contrôle de version (VSS ou Subversion) au cas où vous auriez besoin d'annuler les modifications.

Il existe également des alternatives open source aux classes Microsoft qui sont généralement mieux codées (c.-à-d.Log4Net, nUnit, etc.).Le code Microsoft a tendance à être volumineux et inefficace.

J'ai essayé plusieurs blocs d'application d'Enterprise Lib 3.1 (mai 2007) et voici quelques commentaires :

Bloc d'application de mise en cache :Moins intéressant que System.Web.Caching dans des scénarios simples (comme la mise en cache en mémoire) Gestion et journalisation des exceptions:Trop compliqué.NLog ou Log4Net sont de meilleures solutions.

J'ai regardé les autres blocs mais ils ne semblaient pas adaptés à nos projets.

Finalement, nous avons complètement abandonné EntLib car c'était pénible à personnaliser...Je vous conseillerais de vraiment envisager une solution moins monolithique qu'EntLib.

Nous mettons simplement les binaires EntLib 3.1 dans le cache d'assembly global et ajoutons des références dans nos projets.Cependant, nous utilisons généralement uniquement le framework de journalisation.

Je pense que le moyen le plus pratique consiste à ajouter des blocs d'application\EntLib comme éléments de solution.De cette façon, ils ne seront pas recompilés à chaque fois que vous construisez votre projet (ils ne participeront pas du tout au processus de construction) et vous pourrez facilement accéder à leur code source\définir le point d'arrêt, etc.

Nous utilisons les blocs en ajoutant des références aux DLL, en nous assurant que "copie locale" est défini pour qu'ils soient déployés avec l'application dans le dossier bin de l'application.Cela signifie que nous n'avons pas à nous embêter avec le GAC - c'est beaucoup plus simple !

Lors du débogage, Visual Studio peut toujours accéder au code source même s'il n'est pas directement inclus dans votre projet, à condition que vous disposiez du code source EntLib quelque part sur votre disque dur.Il vous demandera l'emplacement lors de la première utilisation et vous en souviendrez par la suite.

Nous utilisons actuellement les blocs Caching, Exception et Logging.Nous n'avons pas encore pensé à un cas d'utilisation pour le reste.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top