Architecture à trois niveaux et LINQ aux entités

Question

Depuis quelques années, j'utilise l'architecture à trois niveaux (Presentation, Logic et Data Layer) pour écrire des applications. En général, j'utilise des outils tels que .netTiers pour générer la couche de données et partiellement la couche logique. Tout est bien défini et j'adore ça.

Je suis maintenant contraint d'utiliser LINQ to Entites (il semble que LINQ to SQL ait été abandonné par Microsoft) et je suis vraiment confus. Il me semble que le code généré par LINQ to Entites est un mélange important de la couche logique et de la couche de données sur laquelle j'ai très peu de contrôle. De plus, je n'aime pas trop le fait que je doive utiliser les classes (entités ...) générées.

Au final, pourriez-vous partager vos expériences et vos meilleures pratiques avec LINQ to Entities? Avez-vous une idée de la manière dont je pourrais toujours avoir une architecture à trois niveaux bien définie?

Merci!

Answer 1

Ian Cooper a écrit de bonnes séries sur l'architecture de l'application avec Linq2Sql:

• Partie 1 Introduction
• Partie 2: architectures en couches
• Partie 3 DAO et référentiels
• Partie 4 Requêtes dynamiques
• Partie 5
• Partie 6 Mappage avec des fichiers XML au lieu d'attributs
• Partie 7
• Partie 8
• Part 9
• Part 10

J'espère que vous trouverez ce dont vous avez besoin.

Answer 2

L2S n'est pas mort, mais il est fondamentalement complet. C'est une implémentation (adaptateur SQL) pour Linq. Linq est une fonctionnalité linguistique et continuera à se développer à mesure que les versions .net sont publiées.

Ce qui fait la beauté de Linq, c’est la simplicité. Pour ma part, au-delà des fournisseurs supplémentaires (tels que MySql, Firebird, etc.), je ne veux pas vraiment qu'ils s'en servent.