linq2sql - où inscrire la transaction (référentiel ou bll)?

Question

Mon application utilise une couche de gestion qui appelle un référentiel qui utilise linq to sql.

J'ai une classe Item qui a une propriété de type enum et une propriété ItemDetail.

J'ai besoin de mettre en œuvre une méthode de suppression qui:

(1) toujours supprimer l'article (2) si le item.type est XYZ et la ItemDetail est non nul, supprimez le ItemDetail ainsi.

Ma question est où cette logique devrait-elle être logée? Si je l'ai dans ma logique métier que je préférerais, cela implique deux appels de référentiel distincts, chacun utilisant un contexte de données distinct. Je devrais emballer les deux appels est un System.Transaction qui (en sql 2005) est promu à une transaction distribuée qui n'est pas idéale.

Je peux tout déplacer vers un seul appel de référentiel et la transaction sera traitée implicitement par le datacontext mais je pense que c'est vraiment une logique métier qui n'appartient donc pas au référentiel.

pensées?

Carrie

Answer 1

Je ne suis pas sûr d'avoir bien compris votre question, mais si elle est un référentiel unique - Auriez-vous pu exposer votre référentiel deux méthodes différentes de traitement des deux types de suppression? Ensuite, la logique pour déterminer quelle méthode de référentiel à appeler resterait dans le businesslayer où il semble le mieux?

Ou vous pouvez peut-être trouver de l'aide dans ce post: Where should the transaction boundary be in a repository pattern?