82 votes

Dossiers " concerns " et fichiers " .keep " aléatoires.

Je suis en train d'apprendre les rails.

À un moment donné, j'ai remarqué que des dossiers et des fichiers apparemment aléatoires apparaissaient dans le répertoire de mon application Rails. Dans certains dossiers, il y a un concerns avec un .keep en son sein. Le site .keep semble être vide. Dans d'autres dossiers, il n'y a pas de concerns mais un dossier vide .keep est présent.

Quelqu'un sait-il ce qu'il en est de ces fichiers/dossiers ?

125voto

DickieBoy Points 1182

Les fichiers .keep sont des fichiers de 0 octet qui sont là pour empêcher les dossiers vides d'être ignorés par toutes sortes de processus. Rien à craindre.

28voto

lfender6445 Points 1361

Les fichiers .keep sont particulièrement utiles lorsque vous souhaitez livrer des répertoires vides avec git.

Les fichiers .keep sont là pour empêcher le portage d'un vcs à un autre, en supprimant des répertoires importants lorsque vous démontez quelque chose qui ferait que ces répertoires soient vides. Il s'agit d'un paradigme de conception de logiciels qui cherche à diminuer le nombre de décisions que les développeurs doivent prendre, en gagnant en simplicité, mais sans nécessairement perdre en flexibilité.

6voto

prasad.surase Points 2571

Les préoccupations sont un concept simple mais puissant. Il existe pour la réutilisation du code. En gros, l'idée est d'extraire des morceaux de code communs et/ou spécifiques au contexte afin de nettoyer les modèles et d'éviter qu'ils ne deviennent trop gros et ingérables.

Je voudrais préciser explicitement que vous devez utiliser les objets de service pour fournir une fonctionnalité qui ne concerne pas l'objet spécifique. Par exemple, une organisation a de nombreux utilisateurs. Maintenant, l'administrateur de l'organisation a besoin d'exporter un CSV de tous les utilisateurs de cette organisation. Ce code peut être placé dans le modèle d'organisation mais comme il n'est pas de la responsabilité de l'objet d'organisation, ce code devrait être placé dans une classe où vous passez juste l'objet d'organisation et il retourne le CSV de tous les utilisateurs.

 class Services::GenerateCsv
     def self.get_users org
         #add logic the fetch users for the org and generate the CSV and return the CSV data
     end
 end

Chaque fois que vous avez besoin de générer un CSV, vous pouvez placer cette logique dans la classe ci-dessus. Cette approche permet de garder l'objet (dans ce cas, le modèle d'organisation) propre du code qui ne devrait pas être sous sa responsabilité. Un principe général que je suis est : si le code modifie l'objet lui-même, déplacez le code vers un objet de service.

Note : Votre question portait sur les préoccupations, mais j'ai pensé ajouter quelques éléments supplémentaires que je suis pour garder la base de code propre et gérable, car cela pourrait aider les autres programmeurs. L'approche ci-dessus est discutable.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X