Je me suis toujours enseigné à gérer tout code d'accès aux données dans une «couche» complètement distincte de ma logique métier et de mon code d'interface utilisateur. Cela a toujours été une très bonne architecture pour moi et toutes les «règles» ou meilleures pratiques que je vois parviennent toujours à s'intégrer dans ce style de codage, en particulier le principe de responsabilité unique .
Pour la plupart de mes projets à la maison, j'utiliserais mon propre ORM que j'ai créé, que j'ai toujours eu l'intention de rendre open-source. Cependant, depuis lors, LINQ est devenu disponible, ce qui était très similaire à la façon dont mon ORM fonctionnait (mais ... mieux).
Il n'y a rien que je pouvais faire auparavant avec mon propre ORM que je ne peux pas faire maintenant avec LINQ (sauf des bits de l'intégration REST). Donc ma question est; LINQ est-il ma nouvelle couche d'accès aux données? Ai-je encore besoin de cette couche? Mon BLL doit-il simplement parler directement à LINQ? Ou est-ce toujours une mauvaise pratique?
Éditer:
La question d'origine faisait référence à LINQ to Entities, mais il existe de nombreuses réponses intéressantes concernant LINQ to SQL. Que pensent les gens des deux? Je suppose que LINQ to SQL ne peut pas vraiment remplacer un DAL, mais l'entité Framework pourrait-elle?