Validation des données de classe

Question

Dans mon application, je crée une série de classes de validation pour vérifier, par exemple, qu'un utilisateur entré dans la propriété Name de la classe (à partir d'un WinForm) ne dépasse pas la taille de varchar() dans la base de données.

Actuellement, le code de validation lancera une exception personnalisée si le champ Nom est trop grand. (L'exception personnalisée, lorsqu'elle est interceptée par l'interface utilisateur, affiche le message d'exception personnalisé dans un MessageBox par opposition à mon formulaire d'erreur générique pour les exceptions régulières.) Les classes de validation se trouvent dans la bibliothèque de classes de l'application. Le flux ressemble à ceci:

• La fonction publique DLL couche utilisée par les WinForms - (appels) -> Friend Validation couche
• Layer de la fonction publique de la DLL utilisée par les WinForms - (appels) - -> Couche d'accès aux données d'ami si la validation réussit.

Exemple simplifié:

Public Shared Sub CreateCustomer(cust as Customer) 
    Validation.Customer.ValidateForCreate(cust) ' scoped as Friend 
    Dal.Customer.Create(cust) ' scoped as Friend 
End Sub 

est-il la conception « intelligente » pour faire revenir le jet couche de validation des exceptions personnalisées à l'interface utilisateur lorsque la validation échoue?

Est-il préférable de renvoyer True/False à partir du calque Validation avec un message String de ce qui a échoué, et que le niveau de service gère les exceptions de lancement? Est-il préférable de renvoyer Vrai/Faux à partir du Couche de Validation, et de faire en sorte que la Couche Services passe du Vrai/Faux à l'UI avec un message String de ce qui a échoué? J'essaie de garder une approche orientée objet. Mon opinion est que lancer des exceptions personnalisées ne brise pas les principes de la POO, mais j'aimerais d'autres opinions :)

Answer 1

AFAIK le mécanisme d'exception est en fait au cœur de la méthodologie OOP, et est réellement encouragé là où il est intégré dans le langage de programmation. Je dirais que votre validation de lancer une exception personnalisée est une bonne chose, surtout si vous avez plusieurs exceptions personnalisées (NameTooLongException, NameIncludesNonStandardCharactersException ...) qui sont auto-documentées et facilement lisibles par les futurs responsables du code. Une fois que votre exception atteint votre couche de service, vous pouvez décider de l'attraper et de la gérer (cela dépend de votre logique métier) ou la laisser aller jusqu'à l'interface utilisateur. Si l'exception porte un message d'erreur significatif qui est toujours approprié, laisser l'interface utilisateur le présenter à l'utilisateur n'est peut-être pas une mauvaise idée. (N'oubliez pas que vous pouvez vouloir internationaliser votre application à un moment donné, auquel cas le message devra être dans la bonne langue.)

Mon opinion est que la séparation de couches, bien que parfois purement logique, a son raisons, et les exceptions ne devraient pas être jetées du back-end au front-end, mais c'est plus une ligne directrice qu'une règle. Bottom line, faire ce qui doit être fait, ne pas trop penser à la conception.

Hope this helps en quelque sorte ...

Yuval = 8)