Accueil > .Net, Développement > Partage de sessions : Conclusion

Partage de sessions : Conclusion

Ce billet fait partie de la série « Partage de sessions » :

  1. Présentation
  2. Gestion native des sessions en .Net
  3. Focus, State Server
  4. Focus, SQL Server
  5. Focus, Couchbase
  6. Autres possibilités
  7. Conclusion (ce billet)
  8. Annexes

Conclusion de la série des billets.

 

Le document

 

Le document que j’ai du fournir avait deux buts clairement définis : faire état des possibilités et donner des informations pour choisir la solution. Mais aussi un autre but pour la suite : mâcher le travail à ceux qui mettrons en place la solution.
Et ce, à deux populations bien identifiés mais très différentes : décideurs et développeurs.

La lecture n’est donc pas du tout la même, tout comme le niveau d’informations requises.
Pour les décideurs, c’est surtout faisabilité, avantages/inconvénients, coûts (court, moyen, long terme)…
Pour les développeurs, c’est bien plus technique : comment faire, où trouver les informations utiles, où demander de l’aide avant de se pendre, qu’est ce qu’on y gagne ?…

Autant à destination des développeurs, c’est assez simple à écrire (puisque j’en suis un, je sais de quoi j’ai besoin), mais pour les décideurs, c’est plus complexes.

Le but est donc avant tout de faire des parties bien identifiées : certaines s’adressent aux deux populations (qu’est ce que partage de sessions, pourquoi, etc.), d’autres sont plus clairement dédiées à l’une des deux populations (ce qui n’est pas retranscris dans les différentes billets précédents : j’ai condensé, écris pour des développeurs et n’est rien spécifié sur le SI de mon client).

Au final, voici le plan que j’ai adopté :

  1. Introduction (présentation du document, besoins qui ont motivés sa création…)
  2. Etat de l’art (description de l’existant, des possibilités…)
  3. Mise en pratiques (POCs, configuration requises…)
  4. Etude de l’existant (SI du client)
  5. Solutions compatibles (reprises des solutions 1 par 1 pour dire si compatible et si non, pourquoi, comment arranger les choses…)
  6. Conclusion (faisabilité, préconisations avant d’adopter la solution, préconisations de la solution…)
  7. Annexes (définitions, explications de concepts…)

C’est donc un plan relativement simple.
Les points 2, 4 et 5 sont pour les deux populations.
Le point 3 est exclusivement dévolu aux développeurs.
Enfin, le point 1 et les annexes sont surtout destinés aux décideurs.

La conclusion, elle, si elle est pour les deux populations s’organisent autour de plusieurs axes.
Outre la reprise de l’introduction (il faut répondre aux questions qui ont motivé la recherche), il faut répondre à quelques questions, du style :

  • Est-ce que c’est possible en l’état ?
  • Si non, comment y parvenir ? Et a quel coût ?
  • Comment et pour quels coûts (réalisation) mettre en place la solution ?
  • Quels sont les gains ? (maintenance, traçabilité…)
  • Est-ce pertinent d’y aller ? En rapport besoins/coûts (avis de consultant, ici)

 

Points noirs et difficultés

 

La littérature dans le domaine est assez variable.
Certaines sont très complètes mais…obsolètes.
D’autres sont séduisantes, mais…ne fonctionne pas en pratique (ex: des solutions open source à l’arrache et pas mis à jour depuis 2001).
Au final, les recherches dans le domaine sont parfois assez frustrantes.

Il y a aussi une masse importante d’informations à ingurgiter pour les restituer de façon à la fois synthétique et exploitable.
C’est ce qu’il y a de plus dur dans la rédaction de ce type de documents.

Et comme il faut trier, organiser et « élire » des informations (ne retenir que celles qui paraissent pertinentes), il peut être bon de faire une section « Autres possibilités non traitées » pour expliquer pourquoi les solutions sont écartées.
Par exemple : telle solution semble pertinente, mais que sur le site de l’éditeur, elle est très peu mentionnée en dehors et avec un pricing obscur.

Le gros problème est donc de trier, histoire de rendre le document pas trop trop imposant et surtout lisible.
Des tableaux, des graphiques, des images (architectures ou autres) sont donc bienvenue pour aérer le document.
Quand on survole le document, ça fait de suite moins peur.

 

Ma solution préférée

 

Pour les sites standards, avec peu de besoins en ressources et un nombre de visiteurs moyen et régulier, le InProc est amplement suffisant. A mon sens, il n’est pas toujours pertinent de se lancer dans une solution qui n’apporte pas une réelle valeur ajoutée et qui va complexifier les développements. D’autant qu’en respectant des points simples (session légère, objets sérialisables…), c’est relativement simple à changer à posteriori.

Pour les sites de hautes performances avec beaucoup de trafic, les solutions NoSQL me paraissent intéressantes.
Simplement parce qu’elles sont plutôt rapides et pas trop complexes à mettre en oeuvre.
J’ai bien aimé Couchbase qui s’est avéré être très simple à utiliser. En plus, j’ai eu de l’aide, pour le seul problème rencontré, sur leur forum sans problème et assez rapidement. Ce qui fait toujours plaisir.

C’est donc InProc et Couchbase que je retiens, en fonction du besoin.

 

Conclusion

 

La conclusion dans la conclusion \o/

Le sujet fut très intéressant, mais son implémentation requiert pas mal de travail en amont (ou peu si on respecte des règles simples).

Ainsi, il faut veiller à ce que seules les données les plus essentielles sont placées en session.
C’est-à-dire que même si la session est un lieu de stockage assez confortable, il ne faut pas y mettre n’importe quoi.
En général, il faut même essayer de s’en affranchir dès que possible.

Par exemple, si on a très basiquement ceci :

    public class User
    {
        public List<Role> Roles { get; set; }
        // ...
    }
    public class Role
    {
        // ...
    }

Ecrire le code suivant est une mauvaise idée (en passant outre les horribles Magic Strings) :

        public User CurrentUser
        {
            get
            {
                return Session["CurrentUser"] as User;
            }
        }

        public List<Role> Roles
        {
            get
            {
                return Session["CurrentRoles"] as List<Role>;
            }
        }

Ceci sera un peu mieux :

        public List<Role> Roles
        {
            get
            {
                if (CurrentUser != null)
                    return CurrentUser.Roles;
                else return null;
            }
        }

Même si c’est toujours pas top (j’essayerais d’y revenir).

De même, tous les objets placés en session doivent être sérialisables.
Et par là, je n’entends pas seulement les objets de plus haut niveau, mais toute la grappe qu’ils peuvent contenir (composition).
Ça peut poser des difficultés pour certains objets ou collections (je pense aux collections héritant de Dictionary, par exemple).

Bref, avant de songer à déporter les données de la session dans un « autre part », il faut déjà commencer à nettoyer ce que l’on y met !

Catégories :.Net, Développement

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :