Que penses tu de ceci? * tout ce qui est valeurs brutes non configurables par le client lui meme => un fichier de config yml propre a chaque client * chaque comportement => une classe dans un namespace "Strategy"
s'il y a des strategies a differents niveaux, tu fais plusieurs namespaces, genre: Strategy::User, Strategy::Account * la liste des strategies qu'utilise un client => dans le fichier yaml Tu peux tester unitairement chacune de tes strategies Tu peux eclater les fichiers de config en en faisant un par strategie si yen a trop Ton appli est une collection de strategies et un client est juste une combinaison de celles ci (tu peux tester unitairement les combinaison aussi en creant un fichier de spec qui porte le nom du client pour mieux identifier la combinaison) Et pour les "valeurs brutes", tu testes une seul fois la classe qui lit le fichier yaml, tu peux mettre des validations dessus (histoire qu'une appli ne puisse pas demarrer si tu as rajoute une valeur cruciale et que tu as oublie de mettre a jour tes yamls) Tu peux facilement developper une app a cote qui gere ta liste de clients, leurs options et genere des fichiers yaml sur les serveurs (ou capistrano va crawl une url pour recuperer le fichier yaml quand tu deploies, bref, t'as le choix dans la date). Si t'as plus de 3 clients, et que le projet evolue beaucoup, maintenir des classes qui sont juste des matrices de methodes (souvent vides), ca risque de devenir vite l'enfer. Je prefere nettement les fichiers de config quand il s'agit de .... config :p Le 11 avril 2014 03:00, thierry henrio <[email protected]> a écrit : > > > > 2014-04-10 17:30 GMT+02:00 Olivier Gosse-Gardet < > [email protected]>: > > Bonjour, >> >> J'ai une application destinée à plusieurs clients. Chacun de ces clients >> utilisera une instance différente de l'application. Chaque client a des >> propriétés et fonctionnalités différentes. >> Mon idée est d'utiliser des classes différentes héritant d'une classe >> maitre. >> > > composition > inheritance > > >> J'ai donc fait quelque chose comme >> class ClientMain >> end >> >> class Client1 < ClientMain >> end >> >> class Client2 < ClientMain >> end >> >> et défini dans un initializer de rails une sorte d'alias de classe en >> faisant par exemple : >> Client = Client2 >> >> Mon code et mes vues manipulent uniquement Client. >> Tout à l'air de marcher correctement. Ca m'intrigue. >> > > Comment est-ce que tu fais pour tester ton code si Client n'existe que > dans un initializer ? > C'est forcément Client1 ou Client2 > Ou alors tu remplace Client dans tes tests ? > ?? > > Qu'en pensez-vous ? >> > > Ce que j'en pense est que si ça marche pour toi, et bien why not > > Les autres options sont > * engines <http://guides.rubyonrails.org/engines.html> > * lib > + assemblage ( initializers, whatever ) > > , Thierry > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Railsfrance". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
