2010-04-24 7 views
3

Eh bien, je suis nouveau à ce genre de choses ORM. Nous devons créer un grand projet. J'ai lu à propos de LINQ to SQL. sera-t-il approprié de l'utiliser dans le projet à haut risque. Je n'ai trouvé aucun problème personnellement mais le fait est qu'il n'y aura pas de retour en arrière une fois commencé. Donc j'ai besoin de quelques commentaires des gourous ORM ici au MSDN. Le cadre de l'entité sera-t-il meilleur? (Je suis dans le doute sur LINK à SQL parce que j'ai lu et entendu des commentaires négatifs ici et là)Utilisation de LINQ to SQL dans le projet ASP.NET MVC2

Je vais utiliser MVC2 comme cadre. Alors s'il vous plaît donner les commentaires à propos de LINQ to SQL à cet égard. Q2) Aussi je suis un fan de la procédure stockée car ils sont précalculés et attacher la chose et je n'ai jamais travaillé sans eux. Je sais que LINQ to SQL supporte les procédures stockées mais sera-t-il possible d'abandonner la procédure stockée voir la belle couche d'accès aux données générée avec peu d'efforts car nous avons également besoin d'un développement rapide.

Q3) Si quelques modifications à certains champs obligatoires dans la base de données SQL LINK comment les changements sont logés dans la couche d'accès aux données.

+0

Voir ma réponse ici: http://stackoverflow.com/questions/2701952/dump-linq-to-sql-now-that-entity-framework-4-0-has-been-released/2702016#2702016 - - C'est presque la même question, et ma réponse s'applique également ici. –

Répondre

2

Quand il s'agit de Linq-to-Sql vs Entity Framework, je vous suggère fortement d'utiliser Entity Framework. Avec la sortie de .NET 4.0 et VS2010, Microsoft a ajouté tellement de bonté dans Entity Framework (EF) 4.0. Permettez-moi juste de mentionner quelques points: POCO et NTier support (cela signifie que vous pouvez avoir une bibliothèque séparée avec vos classes d'entités simples et bien sûr EF sera toujours au courant), chargement paresseux, optimisations de requête Sql ... Aussi peut laisser EF générer vos entités (et vous avez l'option modifier le modèle de génération T4) ou vous pouvez les créer à la main si vous avez besoin de plus de contrôle. De plus, si votre application sera effectivement grande, avec EF 4, vous pouvez désormais très bien séparer vos calques (vous pouvez créer vos Mocks pour tester etc ...). Je ne suis pas un développeur web, donc je ne peux pas vous donner d'indices sur mvc2 à ce sujet. q2-q3) - dans EF, vous pouvez avoir des requêtes précompilées - SI vous observez plus tard, les performances de cette requête ne sont pas tout à fait ce dont vous avez besoin. Cela va accélérer les choses un peu. Si vous prévoyez d'utiliser EF et si vous ajoutez quelques modifications à votre base de données, vous pouvez facilement mettre à jour votre modèle en un clic. Je sais que je balbutiai trop sur EF et non LINQ to SQL :), mais bon ... Je pense que cela convient bien mieux à vos besoins et vous devriez certainement le vérifier pour ce projet. En outre, je ne sais pas combien Microsoft va ajouter des fonctionnalités/investir dans LinqToSql à l'avenir.

Cheers,

+1

EF4 est toujours une approche à deux couches qui supporte un peu plus de temps système que Linq-to-SQL. Pour les scénarios simples avec SQL Server uniquement, j'aurais toujours tendance à utiliser Linq-to-SQL. Pour les applications d'entreprise et les scénarios plus complexes, rendez-vous sur EF4. –

0

ok requêtes précompilés qui est certainement attrapent mon attention.

+0

Puis-je vous demander, pourquoi avez-vous fait 2 inscriptions? – abatishchev