Comme pour toute règle, je pense que l’important ici est de considérer le but de la règle, son esprit, et de ne pas s’embourber à analyser exactement comment la règle a été formulée dans un manuel et comment l’appliquer à ce cas. Nous n'avons pas besoin d'aborder cela comme des avocats. Le but du règlement est de nous aider à écrire de meilleurs programmes. Ce n’est pas comme si l’écriture de programmes avait pour but de faire respecter les règles.
La règle de la responsabilité unique a pour but de rendre les programmes plus faciles à comprendre et à gérer en permettant à chaque fonction d’agir de manière cohérente et autonome.
Par exemple, j’ai écrit une fois une fonction que j’ai appelée quelque chose comme "checkOrderStatus", qui déterminait si une commande était en attente, expédiée, en rupture de stock, etc., et renvoyait un code indiquant laquelle. Ensuite, un autre programmeur est arrivé et a modifié cette fonction pour mettre à jour la quantité en stock lors de l’expédition de la commande. Cela violait gravement le principe de responsabilité unique. Un autre programmeur lisant ce code plus tard verrait le nom de la fonction, verrait comment la valeur de retour était utilisée et pourrait ne jamais soupçonner qu’il avait mis à jour la base de données. Quelqu'un qui aurait besoin d'obtenir le statut de la commande sans mettre à jour la quantité en stock se trouverait dans une position inconfortable: devrait-il écrire une nouvelle fonction qui duplique la partie du statut de la commande? Ajouter un drapeau pour lui dire si faire la mise à jour de la base de données? Etc.
Par contre, je ne voudrais pas chercher ce qui constitue "deux choses". Récemment, j'ai écrit une fonction qui envoie les informations client de notre système vers le système de notre client. Cette fonction effectue un certain reformatage des données pour répondre à leurs besoins. Par exemple, nous avons des champs qui peuvent être nuls sur notre base de données, mais ils n'autorisent pas les nuls, nous devons donc remplir un texte factice, "non spécifié" ou j'oublie les mots exacts. On peut soutenir que cette fonction fait deux choses: reformater les données ET les envoyer. Mais j’ai très délibérément mis cela dans une seule fonction plutôt que d’avoir "reformater" et "envoyer" parce que je ne veux jamais, jamais envoyer sans reformater. Je ne veux pas que quelqu'un écrive un nouvel appel sans se rendre compte qu'il doit appeler reformater puis envoyer.
Dans votre cas, mettre à jour la base de données et renvoyer une image de la notice écrite semble être deux choses qui pourraient bien aller ensemble de manière logique et inévitable. Je ne connais pas les détails de votre candidature, je ne peux donc pas dire avec certitude si c'est une bonne idée ou non, mais cela semble plausible.
Si vous créez un objet en mémoire qui contient toutes les données de l'enregistrement, effectuez les appels de base de données pour l'écrire, puis renvoyez l'objet, cela a beaucoup de sens. Vous avez l'objet entre vos mains. Pourquoi ne pas simplement le rendre? Si vous n'avez pas renvoyé l'objet, comment l'appelant l'obtiendrait-il? Devrait-il lire la base de données pour obtenir l'objet que vous venez d'écrire? Cela semble plutôt inefficace. Comment trouverait-il le disque? Connaissez-vous la clé primaire? Si quelqu'un déclare qu'il est "légal" pour la fonction d'écriture de renvoyer la clé primaire afin que vous puissiez relire l'enregistrement, pourquoi ne pas simplement renvoyer l'intégralité de l'enregistrement afin que vous n'ayez pas à le faire? Quelle est la différence?
D'autre part, si la création de l'objet est un travail assez différent de l'écriture de l'enregistrement de base de données, et qu'un appelant peut très bien vouloir effectuer l'écriture mais ne pas créer l'objet, cela peut être une perte de temps. Si un appelant peut vouloir l'objet mais ne pas écrire, vous devez alors fournir un autre moyen de l'obtenir, ce qui peut signifier l'écriture de code redondant.
Mais je pense que le scénario 1 est plus probable, donc je dirais, probablement pas de problème.