J'ai une certaine logique comme celle-ci, avant de sauvegarder le stock dans la base de données, je vérifierai s'il ya un stock a le même code de stock dans la base de données. Ma question est de savoir où dois-je mettre la logique, dans la couche de service ou dans la couche de référentiel. Voici le code d'exemple:
Option 1: Mettez la couche de service, je mets la méthode ISaccounttalreadyExists dans la couche de service
public override void Save(AccountInfo accountInfo)
{
try
{
using (var scope = new TransactionScope())
{
accountRepository.Save(accountInfo);
scope.Complete();
}
}
catch(AccountAlreadyExistedException e)
{
...
}
}
5 Réponses :
Depuis que vous avez demandé des opinions, c'est ici. :-) Placez la logique de validation à la couche la plus basse la plus proche des données. Donc, dans ce cas, la logique devrait être dans le référentiel. Le service peut attraper l'exception et le traduire s'il le souhaite. Mais les critères que "comptes devraient être uniques" est une caractéristique du référentiel, imo.
Je l'aurais mis dans la couche de service. Le référentiel gère la logique de persistance.
C'est la responsabilité du service d'appeler à d'autres objets pour faire le travail.
Je préfère mettre les chèques les plus proches des données - donc dans ce cas, ce serait la base de données.
Je ferais une contrainte unique en fonction des conditions que vous faites pour vous assurer que le compte n'existe pas. Cela garantirait que personne ne peut contourner mon niveau moyen et insérer des données mauvaises.
alors je peux mettre la vérification dans la couche de référentiel comme précaution supplémentaire.
Service - Les modèles de répositoires peuvent être un peu subjectifs. Bien sûr, il existe des exemples mauvais / complètement incorrect (celui-ci Le modèle que j'ai tendance à suivre est que la couche de référentiel doit être dédiée à 99% aux opérations de suppression de lecture-écriture avec votre source de données. La seule validation que ma couche de référentiel effectue est une validation de très bas niveau sur les modèles: ceci est généralement effectué via une méthode Model.isvalid. Il vérifie uniquement les champs requis et le format / de base de ces champs (par exemple une vérification REG-EX d'un champ censé contenir et envoyer un courrier électronique). La couche de référentiel ne tente pas de donner un sens à ces erreurs - si le modèle n'est pas valide, il jette une exception, et cela met fin à la manipulation.
Les contrôles logiques de l'entreprise doivent être effectués dans la couche de service. Si des objets utilisateur sont autorisés à être "assignés" à un modèle particulier ("Joe Possède un disque X"), la couche de service doit exécuter les chèques pour s'assurer que Joe est autorisé à posséder cet enregistrement, etc. à compléter, ma couche de service généralement vérifie également la méthode ISVALID sur le modèle également, afin de préempter des exceptions de couche de données.
Mon seul commentaire avec votre code d'exemple est avec le nom de la méthode "Enregistrer" - c'est trop ambigu. Je préfère créer / inserter et mettre à jour - il est clair que ce premier entraînera un nouvel enregistrement créé (à l'ampleur occasionnelle que je remplace le champ ID de l'objet avec une nouvelle valeur), tandis que ce dernier devrait mettre à jour un enregistrement, et ainsi lancerait une exception si aucune valeur d'identification n'est transmise.
Je considère que ceci soit trois niveaux (avec une interface définie pour connecter chaque pièce):
De cette façon, si vous choisissez de stocker vos données d'une autre manière, la logique de validation ne se perd pas avec elle.
De même, si vous décidez de fournir une autre forme d'accès client, vous le faites sans avoir à reproduire un tas de logique.