Développement d'une application de niveau entreprise à l'aide de LINQ

Question

L'utilisation de LINQ to SQL accélère le développement d'applications, mais dissout les couches logiques dans l'application. La couche d'accès aux données et les couches d'objets métier n'ont presque pas d'identité, elles se trouvent dans la même DLL. Est-ce que quelqu'un a une idée sur la façon de développer une application au niveau de l'entreprise en utilisant LINQ to SQL. Comment sépare-t-on proprement l'objet métier et les entités générées par LINQ? Comment communiqueraient-ils, comment les données seraient-elles transférées entre nos objets de gestion et les entités LINQ? Tout article ou toute suggestion à ce sujet serait grandement apprécier. Merci.

Answer 1

Nous utilisons L2S pour notre prochaine génération de logiciels qui gère les opérations de notre usine et les applications connexes. C'est pour une compagnie solaire de film mince de $ 2.5B. Nous avons construit un cadre d'application n-tier basé sur L2S clairement défini.

Nous avons également créé notre propre générateur de code pour générer un ensemble d'entités, un ensemble d'entités L2S, une couche logique métier et une couche d'accès aux données. L'ensemble d'entités L2S est réservé à l'utilisation principale. Les entités d'application (qui n'ont pas de plomberie L2S intégrée) servent à transférer des données d'une application à l'autre. Nous utilisons WCF pour la communication de niveau application à niveau serveur.

Nos applications utilisent WCF pour appeler la couche logique des bus de back-end pour le traitement des données. La couche logique métier appelle notre couche d'accès aux données pour un accès bas niveau aux données Linq. Nos entités d'application sont transmises vers et depuis notre back-end. Dans le back-end, nous avons un mappage très efficace qui mappe une entité d'application à chaque entité L2S.

Fonctionne très bien pour nous.

Randy

Answer 2

Vous pouvez aller très loin avec L2S (comme StackOverflow a prouvé), mais à mon humble Linq2SQL ne convient pas (ni prévu, je pense) pour « applications de niveau entreprise ». Maintenant que Entity Framework 4.0 a été publié, vous pouvez envisager d'utiliser EF à la place. Il prend en charge POCO et vous permettra d'avoir une architecture en couches beaucoup plus agréable.

Départ:

The ADO.NET Entity Framework

ADO.NET C# POCO Entity Generator

J'ai récemment porté une base de code substantiel de L2S à EF 4.0. Comme EF supporte maintenant le chargement paresseux, vous pouvez avoir une transition très douce de L2S à EF, en tirant parti des fonctionnalités avancées de EF uniquement lorsque vous en avez besoin.