ICandidate vs TEntity

[nfaugout-lucca]

J'ai un pb sur le CreateAsync( ) à cause de ICandidate.

ICandidate est très pratique quand on arrive depuis la couche web, car il permet de "tester" et/ou de valider l'entité candidate AVANT d'appeler le Domain.

A l'inverse, depuis un test où on veut juste tester le code métier d'une Collection, devoir envoyer un ICandidate est déroutant, on aimerait envoyer directement un TEntity comme avant.

Je vous propose les évolutions suivantes :

• la validation des entités est lancée depuis la couche Application. Ainsi toutes les req arrivant du web prennent un ICandidate, et ont la validation jouée dans Application

• une fois la validation OK, la couche Application appelle le Create des collections avec le .Value des ICandidate, càd avec un TEntity

Ainsi, le Domain raisonne sur des objets valides uniquement, ça me semble une "bonne pratique".

D'ailleurs dans le DDD il est conseillé que les entités d'auto valide dès l'instanciation, càd qu'il ne soit pas possible de créer une entité dans un état invalide. Ce serait un peu l'idée ici.

@rducom @Poltuu Si vous êtes OK je fais la PR sur la v3.0 car ça me semble un choix structurant et la version actuelle n'est pas ouf :'(

[rducom]

Si le Domain doit raisonner sur les objets valides, alors c'est à la couche Web de valider (ou prévalider) ces entités. Et ça tombe bien, aspnet est fait pour ça.

Voici mes réflexions autour de cette issue :

• Actuellement on ignore la validation standard aspnet (qui alimente le ModelState.IsValid d'un controller). Ce serait bien qu'on puisse retomber sur le standard à ce niveau, permettant ainsi d'utiliser des DataAnnotationAttribute, ou des ValidationAttributes
• Selon moi, la couche Domain devrait ne prendre en entrée QUE les objets, pas des ICandidate
• On a besoin des ICandidate jusqu'à la couche collection aujourd'hui pour princapelement pour le PUT qui fait un appel Db, c'est pas l'idéal de généraliser le ICandidate partout alors qu'il ne concerne que le PUT
• On construit ICandidate aujourd'hui dans le WebController, alors qu'on pourrait externaliser dans un Custom Model Binder, et ainsi, ne plus avoir besoin de relire le body plusieurs fois.

[nfaugout-lucca]

Je suis d'accord pour que le modèle ne raisonne que sur des objets valides.

Par contre, si ce que tu proposes conduit à mettre de la data annotation sur les entités du Domain pour que la couche web puisse valider "plus facilement", ça ne me va pas, même si c'est "une bonne façon de faire". Car l'idée derrière ce qu'on fait depuis le départ c'est d'éviter de polluer le Domain avec des considérations techniques et/ou externes.

Donc je ne baserais pas notre modèle de Validation sur les DataAnnotations. Après que ce soit possible de le faire, pourquoi pas : càd un projet qui décide de les autoriser et de baser sa validation dessus, pas de pb. Mais que Rdd repose dessus bof..

Sur les responsabilités, je voyais plutôt la couche Application, qui sert d'interface entre les appels venant de l'extérieur (web mais pas que) et le Domain. A la limite si la couche web fait de la prévalidation sur des genres de DTO pourquoi pas, mais dans Rdd je mettrais la validation "métier" déclenchée depuis la couche Application.

NB : s'il devient impossible de fabriquer un objet du Domain invalide, alors ça sous entend qu'on ne peut pas pré-instancier un objet du Domain puis tenter de le valider ! La validation sera soit embarquée dans l'objet (sous forme de DataAnnotation ou carrément dans les constructeurs de l'objet), soit faite sur autre chose que les entités du Domain : sur des DTO Web par ex.

Il faut bien garder tout ça en tête dans cette réflexion.

[rducom]

Les DataAnnotations sont pas obligatoires, on peux tout faire par ValidationAttributes, et moi aussi je déteste poluer les poco avec des attributs

impossible de fabriquer un objet du Domain invalide

ça me parait compliqué.... EF peut potentiellement créer des objets invalides.

[nfaugout-lucca]

Je propose qu'on mette ça sur la table pour la 3.1, j'ai bien envie d'essayer, vu que EF est compatible avec les constructeurs non vide désormais ;)

[Poltuu]

Je pense que le chantier suivant sur RDD, si on a le temps, sera la partie édition. Une grosse passe a été faite sur la v3 notamment sur la lecture, mais l'édition est passée sous le radar dans l'ensemble.

Il faut sans doute regarder ce que aspnet core/ ef core etc proposent aujourd'hui qui n'existaient pas à la naissance de rdd qui pourraient nous être utile, comparer en perf/standard/lisibilité/breaking change/fonctionnalité, et arbitrer ensuite sur ce que l'on choisit, icandidate ou autre chose.

On voit bien aussi que notre changement de position sur la validation va conduire à des braking changes sur le sujet, donc je sui d'avis de lancer la discussion, mais en gardant en échéances la version suivante RDD, pour nous permettre de nous donner le temps