Linq à SQL ou entités, à ce stade?

Je suggérerais d'aller avec des entités ou de NHibernate, Linq très étroitement couplé la base de données sur vos objets de domaine, qui sont ensuite utilisés par votre couche de présentation. Cela se retrouvera avec un couplage serré de la couche de présentation à la base de données, qui a tendance à ne pas être souhaitable.

Personnellement, j'aime l'entité Framework 4.0, vous pouvez utiliser des requêtes LINQ avec des objets IT et POCO que vous vous codez. Il gère simplement toutes les choses de base de données / SQL pour vous.

Cet article est similaire à l'article de Hanselman. Il compare DataReader (qu'ils appellent "accès" de données "connectés"), Dataset tapé ("déconnecté"), LINQ vers SQL et Framework. Des exemples de code détaillés sont donnés pour toutes les approches, ainsi que les avantages et les inconvénients de chaque approche.

Y a-t-il une raison d'utiliser LINQ vers SQL, ou devrais-je simplement passer à des entités? P>

Je suis à peine objectif (comme un utilisateur de Linqtosql matrice), mais cela est responsable. P>

Les technologies de cartographie relationnelles de l'objet sont des tentatives de résolution ou d'atténuation de l'inadéquation d'impédance relationnelle. Ce sont des ponts entre les deux mondes - le monde de l'objet et le monde des données relationnels. P>

Et il semble que les développeurs de ces ponts appellent généralement un côté ou l'autre, à la maison. P>

LINQTOSQL est un orm du côté objet. Il a été développé par l'équipe C # et vous permet d'utiliser des objets pour représenter des données. Dans LINQTOSQL, il n'y a pas de chaînes opaques compilatrice, toutes les requêtes sont vérifiées par le compilateur contre le mappage. P>

EF est un orm du côté des données. Il a été développé par l'équipe ADO et vous permet d'utiliser des données représentées comme des objets. En EF, il y a beaucoup de chaînes opaques. P>

Les requêtes doivent finalement exécuter une base de données et le compilateur ne peut pas certifier que la base de données disponible au temps d'exécution correspond au mappage (true dans l'une ou l'autre des ormes). En raison de cette réalité du monde des données, l'équipe de données ne value pas la valeur des garanties de compilateur autant que l'équipe C #. P>

ayant travaillé dans un backend TSQL pendant des années, sans la protection d'un compilateur, je me passe Pour valoriser pleinement n'importe quelle aide, le compilateur va me donner. Et alors je suis du côté de l'équipe C # à ce sujet. P>

---

Par exemple, chargement d'un client avec ses commandes. P>

  //linq to sql.
DataLoadOptions load = new DataLoadOptions();
load.LoadWith<Customer>(c => c.Orders);  //<-- strong typed
myDataContext.LoadOptions = load;

IQueryable<Customer> query = myDataContext.Customers
  .Where(c => c.CustomerId == 1);

  //entity framework
IQueryable<Customer> query = myObjectContext.Customers
  .Include("Orders")  // <-- opaque string
  .Where(c => c.Customer.Id == 1);