Protobuf-net utilise un modèle de stratégie ; selon les besoins (une seule fois par type), il utilise la réflexion pour examiner les types, et construit un ensemble de sérialiseurs (basés sur une interface commune) qu'il peut utiliser pour sérialiser et désérialiser - donc lors de l'utilisation il ne fait que passer par l'ensemble des sérialiseurs connus.
À l'intérieur de qu'elle tente de faire un usage judicieux de la réflexion lorsqu'elle s'adresse aux membres ; elle utilise Delegate.CreateDelegate pour parler des propriétés, et DynamicMethod (et IL personnalisée) pour parler aux champs (lorsque cela est possible ; cela dépend du framework cible). Cela signifie qu'il parle toujours à connu sous le nom de types de délégués, plutôt que simplement DynamicInvoke (ce qui est très lent).
Sans devenir fou, le code comporte quelques optimisations (sans doute au détriment de la lisibilité) en termes de.. :
- local
byte[] mise en mémoire tampon (des flux d'entrée/sortie)
- l'utilisation de tableaux de taille fixe (plutôt que des listes, etc.) ; peut-être trop
- utiliser des génériques pour éviter la mise en boîte
- de nombreux ajustements/twiddles/etc autour des boucles de traitement binaire
Avec le recul, je pense que j'ai fait une erreur sur le point des génériques ; la complexité signifiait que forcer les génériques dans le système le déformer à quelques endroits et cause activement des problèmes majeurs (pour les modèles complexes). sur le cadre compact .
J'ai quelques idées (dans ma tête seulement) pour remanier cela en utilisant non -et, au lieu de cela (pour les cadres appropriés), faire davantage appel aux interfaces génériques de l ILGenerator (mon premier choix aurait été Expression mais cela oblige à utiliser une version plus élevée du framework). Le problème, cependant, c'est que cela va prendre un temps considérable pour fonctionner, et jusqu'à très récemment, l'équipe d'experts de l'IRC a fait des progrès considérables. J'ai été plutôt débordé .
Récemment, j'ai réussi à recommencer à passer du temps sur protobuf-net J'espère donc que je vais pouvoir rattraper mon retard en matière de demandes et m'y atteler bientôt. J'ai également l'intention de le faire fonctionner avec des modèles. otros que la réflexion (c'est-à-dire en décrivant séparément le mappage des fils).
et ne produit pas de code généré
Je dois également préciser qu'il existe deux itinéraires de codegen (facultatifs) si vous souhaitez utiliser du code généré ; protogen.exe, ou le fichier Complément VS permettent de générer du code à partir d'un fichier .proto. Mais ce n'est pas nécessaire - Il est utile principalement si vous avez un fichier .proto existant, ou si vous avez l'intention d'interagir avec un autre langage (C++, etc.) pour un développement basé sur des contrats.
