Dapper par rapport à la conception n-Tier (BLL / DAL)

bll business-logic-layer dapper data-access-layer

Question

J'ai une question logique de base sur Dapper.

En essayant de faire les meilleures pratiques de conception, Dapper brouille-t-il la ligne entre DAL et BLL? Beaucoup de recommandations sont que le DAL ne devrait rien savoir sur le BLL et que le DAL devrait juste renvoyer un blob de données que le BLL devrait convertir en un objet utile.

J'aimerais avoir l'avis de certains experts ici sur la place de Dapper.

C'est un excellent projet, qui fonctionne très bien, mais il semble étroitement lié au BLL. Je ne suis pas personnellement opposé à cette approche, mais je me demandais si 1) il y avait un meilleur moyen de découpler Dapper et BLL, ou 2) si ce n’est pas un problème réel car nous ne prévoyons pas de quitter MS SQL.

Merci.

EDIT: en réponse au commentaire de Marc:

Dapper est un excellent produit et ce n'est pas un claquement de quelque manière que ce soit ... Ce que je veux dire par couplage avec le BLL, c'est que lorsque vous exécutez une requête, elle va souvent 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 retournera une collection de Dog.

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.

Beaucoup de recommandations sont que le DAL ne devrait jamais rien savoir sur le BLL. J'essaie simplement de déterminer les meilleures pratiques pour déployer Dapper et conserver une bonne structure de conception N-Tier.

Je sais que c'est quelque peu subjectif, mais si c'est suffisant pour alimenter Stack Overflow, vous devez tous avoir compris la meilleure façon de le déployer dans un environnement bien conçu.

EDIT: Remarqué que le type de "Dog" n'était pas affiché dans l'exemple de requête en raison des symboles HTML.

EDIT à 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 la DAL. Pour plus de clarté, nous pouvons supposer que nous avons une solution avec le DAL et le BLL en tant que projets de classe séparés. Maintenant, lorsque cette ligne de code entre dans le projet DAL, le DAL devra référencer le BLL pour obtenir l'objet "Dog". Est-ce que cette dépendance croisée va bien? ou juste la façon dont le Dapper est le plus couramment utilisé? Ou est-ce une mauvaise pratique et tout simplement pas la meilleure façon d'utiliser Dapper? Je sais que beaucoup de «puristes» diraient que le DAL ne devrait rien savoir au sujet du BLL. Cependant, la ligne ci-dessus semble être l'exemple d'utilisation le plus courant de Dapper.

Réponse acceptée

Considérez dapper comme un rack pour les bases de données, à lire: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

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

Il ne va pas vous dire où placer votre logique métier. Si vous souhaitez brouiller votre logique d’entreprise 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. C'est une technologie simple d'accès aux données.


Réponse populaire

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 le suggère votre question), mais de la classe, de l'espace de noms et même du chemin d'accès au fichier source dans un projet avec le code de ligne. Beaucoup de fois, ces problèmes sont ignorés par les programmeurs qui veulent écrire un bon DAL et BLL et pensent que s'ils utilisent le bon outil, le problème est résolu instantanément.

Permettez-moi de vous donner quelques exemples basés sur la ligne de code que vous avez fournie ci-dessus pour clarifier mon propos.

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 difficulté. Le projet n'est pas à n-tiers ou modulaire.

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

Une conclusion similaire peut être tirée si elle se trouvait dans un répertoire appelé BLL.

Ne manquez pas de comprendre mon point - je ne suggère pas que vous devez avoir un nom de répertoire 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 de n-tier bien conçu ou en nuire.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi