Dapper par rapport à la conception de niveau N (BLL / DAL)

Question

J'ai une question logique de base sur le dapper.

En essayant de faire les meilleures pratiques de conception, le dapper brouille-t-il la ligne entre Dal et BLL? De nombreuses recommandations sont que le DAL ne devrait rien savoir du BLL et que le DAL devrait simplement renvoyer une goutte de données que le BLL doit convertir en un objet utile.

Je voudrais avoir l'opinion de certains des experts ici sur l'endroit où s'intègre.

C'est un excellent projet, et fonctionne très bien, mais il semble étroitement couplé au BLL. Je ne suis pas personnellement opposé à l'approche, mais je me suis demandé si 1) il y avait une meilleure façon de découpler Dapper et BLL, ou 2) si ce n'est pas un vrai problème car nous ne prévoyons pas de nous éloigner de MS SQL.

Merci.

Edit: en réponse au commentaire de Marc:

Dapper est un excellent produit et ce n'est pas un slam en aucun cas ... ce que je veux dire par couplé au BLL, c'est que lorsque vous exécutez une requête, il va généralement renvoyer une collection d'un type spécifique.

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

Dans ce cas, la requête renverra une collection de chiens.

Si Dapper était déployé dans la couche DAL, il devrait avoir une référence à la couche BLL afin de connaître les types d'objets qu'il va retourner.

De nombreuses recommandations sont que le DAL ne devrait jamais savoir sur le BLL. J'essaie juste de rédiger les meilleures pratiques pour déployer le dapper et garder une bonne structure de conception de niveau N.

Je sais que c'est quelque peu subjectif, mais s'il est assez bon pour le débordement de pile d'alimentation, alors vous devez tous avoir trouvé le moyen de la meilleure pratique pour le déployer dans un environnement bien conçu.

Edit: a remarqué que le type de "chien" n'a pas été montré dans l'exemple de requête en raison des symboles HTML.

Modifiez à nouveau en réponse aux commentaires de Hogan: Le cœur de ma question est davantage lié à l'idée que la ligne de code ci-dessus serait dans le DAL. Par souci de clarté, nous pouvons supposer que nous avons une solution avec le DAL et le BLL en tant que projets de classe distincts. Maintenant, lorsque cette ligne de code va dans le projet DAL, le DAL devra référencer le BLL pour obtenir l'objet "chien". Cette dépendance croisée est-elle correcte? Ou juste la façon dont le pimpant est le plus couramment utilisé? Ou est-ce une mauvaise pratique et tout simplement pas la meilleure façon d'utiliser le pimper? Je sais que de nombreux «puristes» diraient que le dal ne devrait rien savoir sur le BLL ... s'appuyer sur l'objet "chien" dans la ligne ci-dessus violerait ce principe. Cependant, la ligne ci-dessus semble être l'exemple le plus courant de l'utilisation du pimpant.

Answer 1

Considérez le dapper comme un Étagère Pour les bases de données, lisez: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper ne vous oblige pas à utiliser des référentiels ou des modèles particuliers.

Cela ne vous dira pas où mettre votre logique commerciale. Si vous souhaitez embrouiller votre logique commerciale avec votre code d'accès aux données, qu'il en soit ainsi. Si vous ne le faites pas, ne le faites pas. Dapper est agnostique. Il s'agit d'une technologie simple d'accès aux données.

Answer 2

Je pense que votre question ignore le contexte. Dal et BLL concernent souvent le contexte. Il ne s'agit pas d'une seule ligne de code (comme votre question le suggère) mais de la classe, de l'espace de noms et même du chemin d'un projet dans le fichier source avec le code de ligne. Plusieurs fois, ces problèmes sont ignorés par les programmeurs qui souhaitent écrire un bon DAL et BLL et pensent que s'ils utilisent le bon outil, le problème est instantanément résolu.

Permettez-moi de vous donner quelques exemples en fonction de la ligne de code que vous avez fournis ci-dessus pour indiquer clairement mon point.

Si je lisais le code source d'un projet et que je trouvais cette ligne de code dans un fichier * .aspx.cs, je serais un peu en détresse. Le projet n'est pas n-niveau ni modulaire.

Inversement, si je lisais la source et que je trouvais cette ligne de code dans un fichier appelé dog.cs dans le sous-administrateur DAL d'un projet, il serait clair que le code est destiné à agir comme accès aux données pour les objets Dog dans la solution.

Une conclusion similaire peut être tirée si elle était située dans un répertoire Call BLL.

Ne manquez pas de comprendre mon point - je ne suggère pas que vous deviez avoir un répertoire Nommez Dal et BLL dans votre solution - je dis simplement que ce qui définit ces éléments est externe à une section de code qui effectue un accès aux données . Une telle ligne de code pourrait contribuer à un système N de niveau N bien conçu ou en nuire.

Answer 3

Nous utilisons le dapper dans nos couches de référentiel / de données comme un moyen rapide et facile de cartographier nos données à nos objets sans écrire de code supplémentaire pour faire le mappage. C'est à vous de savoir si vous souhaitez utiliser DTOS pour transférer vos données entre les couches ou la carte directement vers vos entités (BOS) qui peuvent être dans une couche commune distincte.

Tout dépend du niveau d'abstraction que vous souhaitez mettre en œuvre. Si vous utilisez Entity Framework et créez vos requêtes LINQ directement dans votre couche d'entreprise, vous associez étroitement votre logique à EF et vos entités sont également utilisées dans votre couche de données et votre couche commerciale.