Salut à tous,
Je me pose une petite question concernant la gestion des exceptions de ma DAL, qui utilise LINQ (comme vous l’aurez remarqué dans le titre du topic 
)
Une fois que le schéma de la base de données est bien défini, LINQ To SQL se charge de lancer des exceptions en cas d’erreurs…
Par exemple, j’ai une table Players avec un champ varchar FirstName et un champ varchar LastName, qui ne peuvent pas être null, et pour lesquels une Unique Key a été définie.
Soit la fonction AddPlayer de ma DAL:
[code]public Player AddPlayer(Player newPlayer)
{
var dc = CreateDataContext();
dc.Players.InsertOnSubmit(newPlayer);
dc.SubmitChanges();
return newPlayer;
}[/code]
Si le paramètre newPlayer est null, alors LINQ lance une exception ArgumentNullException avec le message System.ArgumentNullException: Value cannot be null.
.
Si newPlayer.FirstName est null, alors LINQ lance une SQLException avec le message System.Data.SqlClient.SqlException: Impossible d’insérer la valeur NULL dans la colonne ‹ FirstName ›, table ‹ Test_Ex_MVS.dbo.Players ›. Cette colonne n’accepte pas les valeurs NULL. Échec de INSERT.
Si j’insère un player qui est déjà dans la base, j’ai une autre SqlException, etc…
La question que je me pose est donc de savoir ce qu’il vaut mieux faire avec ces exceptions:
[ul]
[li]Laisser les exceptions LINQ se lancer, les récupérer dans la DAL pour en lancer d’autres, éventuellement personnalisées?[/li][li]Laisser les exceptions LINQ se propager pour les intercepter dans une couche de plus haut niveau?[/li][li]Faire en sorte dans la DAL (ou dans une couche supérieure? c’est peut-être le rôle de la BLL?) que ce genre d’exceptions n’arrive pas?[/li][/ul]
Je me pose cette question car j’étais en train d’écrire des tests unitaires pour une DAL qui fonctionne avec LINQ, et j’avais l’impression en gérant les cas de plantage de faire du boulot inutile dans la mesure où LINQ lance déjà les exceptions qui vont bien…
Je penche quand même pour gérer les exceptions moi-même dans la mesure où les exceptions SQL sont toutes du type SqlException, et c’est galère du coup pour différencier le cas où il y a une violation de clé unique ou une tentative d’insérer une valeur nulle pour champ qui le supporte pas, et du coup créer mes propres exceptions UniqueKeyException, DataFieldNullException, etc…
Et dans ce cas, j’en reviens au problème d’origine: où faire cette gestion d’exceptions? C’est le rôle de quelle couche? DAL ou BLL?
Merci d’avance pour vos conseils éclairés :crying:
Mike