J'aimerais que vos opinions concernant "DataSet Designer" et DAL (couche d'accès aux données) meilleures pratiques. J'utilise le cadre de Visual Studio 2010 .NET 4.0.
Pour ma compréhension, "DataSet Designer" permettez-moi de créer automatiquement un jeu de données Strictement dactylographié avec DataTable et adaptateur, cela consiste en DAL directement dans Visual Studio 2010.
J'aimerais savoir: - Si dans le scénario réel, "DataSet Designer" fonctionne bien, ou c'est mieux écrire un objet métier personnalisé. - S'il existe une autre nouvelle solution introduite dans .NET 4.0
Merci pour votre soutien! : -)
10 Réponses :
Je préférerai personnellement des objets commerciaux personnalisés avec leur flexibilité, mais sa plus de travail. Regardez également avec l'entité Framework et Linq à SQL. Entity FX a beaucoup plus de flexibilité dans .NET 4.0. Ce L'article devrait vous aider à démarrer sur l'entité FX.
Je suggérerais un Les ensembles de données sent trop à la base de données de la base de données et j'ai personnellement eu beaucoup de problèmes de travailler avec eux. Ils sont juste cassés assez souvent et lancent des erreurs étranges difficiles à résoudre.
Quelques autres questions connexes que vous pouvez trouver intéressantes
orm comme Framework d'entité ou NHibernate .
Utilisez le cadre d'entité ADO.NET, qui est là où se déroule l'avenir de l'orme de Microsoft. Ou considérons une source ouverte comme NHibernate ...
hth.
Avec l'avènement du Cadre .NET 4.0 et l'introduction de LINQ à SQL, j'ai adopté une DAL d'objets personnalisés d'affaires strictement écrites. Nous avons expérimenté brièvement le cadre d'entité, mais a finalement conclu qu'il est très similaire aux jeux de données en ce que le code généré automatiquement, tandis que Handy, est tout simplement trop gonflé avec une indemnaire supplémentaire que nous n'avons finalement pas utilisé.
Nous avons constaté que l'écriture de Linq dans notre DAL et l'extraction de données tire dans nos classes personnalisées, nous sommes en mesure de rationaliser notre accès aux données et de contrôler l'utilisation des données fonctionnellement. Ce fut un processus très pratique, mais cela a pris un peu pour les développeurs juniors pour l'adhérer.
+1 pour expliquer brièvement que l'on peut être critique à propos de EF. En effet, il a (tout à fait) des inconvénients. Personnellement, j'utilise toujours NH, beaucoup plus flexible et aucun impact sur la DB du tout.
Vous devriez examiner le nouveau cadre d'entité «code-premier». C'est comme utiliser Nibernate fluide uniquement avec EF. C'est très maigre imo. Le seul inconvénient est qu'il est toujours en CPT (actuellement 4), mais très cool de jouer avec. Consultez le blog EF pour plus d'informations: blogs.msdn .Com / B / Adonet / Archive / 2010/07/14 / ...
@Thecloudlesssky - Je vais donner un coup d'oeil. Nous pêchons toujours sur une nouvelle norme depuis que nous sommes entre des projets majeurs, alors merci pour la lecture.
NHibernate. Surtout si vous utilisez Oracle.
Je suis personnellement d'accord avec Joel Etherton, conditionnellement.
Si vous avez un petit projet suffisant que même avec BLOQUE EF, vous ne regardez toujours pas trop de Code de Shenanigan, je dirais que l'opportunité qu'elle offre est en vaut la peine. Toutefois, dans des cas de code plus vastes, il peut devenir beaucoup pour que vos mains soient tendues autant de gonflage.
L'autre avantage pour les objets commerciaux de style EF vs vs VS qui ne va pas, est avec la mise en œuvre EF, vous obtiendrez probablement des mises à niveau plus faciles aux nouvelles versions .NET en tirant parti des avantages dans le prochain .net sans avoir à réécrire un tas de code. par la main. (Cela peut également être une épée à double tranchant que la mise à niveau vers de nouveaux .NET avec EF peut affecter le comportement de votre DAL par opposition à un dal écrit à la main est moins susceptible d'être si affecté.)
Cela dit, je suis d'accord avec Joel Etherton, écrivez le plus petit dal le plus simple que vous puissiez implémenter LINQ, le DAL est toujours trop important pour rendre trop complexe chaque fois que cela peut être évité.
Je dois travailler avec des jeux de données typés et c'est un cauchemar. Si vous avez une option, ne les utilisez jamais. Tout va mieux.
Alors, que recommandez-vous d'utiliser?
Si vous n'avez pas besoin de mappage complexe: POCO + Standard Ado.NET ou LINQ-TO-SQL. Si vous avez besoin de cartographie complexe NHibernate + POCO ou EF4 + POCO. Les jeux de données sont la technologie de .NET 1.X. Il y avait des mises à jour dans .NET 2.0 mais ces mises à jour les rendent pires encore.
Si vous ne voulez pas vous perdre du temps, n'apprenez pas de jeux de données. Étudier les concepts généraux de cartographie d'objet-relationnel, de leurs avantages et des inconvénients. Regardez des projets comme Hibernate pour Java ou Doctrine pour PHP. Approches derrière les datables et les jeux de données qui fournissent juste l'emballage des objets de base de données sont terminés. Votre cadre devrait vous guider pour concevoir votre modèle de domaine, pas le schéma de base de données.
chez mon entreprise Nous utilisons des jeux de données typés depuis un peu de temps et j'ai eu une expérience généralement positive. Je comprends que beaucoup de gens n'aiment pas les jeux de données, et il existe certainement des outils d'accès aux données plus récents, mais que vous avez posé des questions sur un scénario réel, voici quelques-unes de mes exigences et constatations:
J'ai personnellement exploré l'accès ADO.NET à bas niveau, des jeux de données dactylographiés, LINQ-TO-SQL et simplement écrire des classes d'accès aux données personnalisées. Je n'ai pas encore examiné le cadre d'entité, car la version incluse dans VS2008 semblait avoir des critiques mitigées, et je n'avais pas accès à VS2010 jusqu'à ce que récemment (je prévois de revoir EF un jour de cette année).
Nous avons choisi d'utiliser des ensembles de données dactylographiés car ils semblaient offrir un développement plus rapide contre les Sprates et nous avons trouvé un tutoriel très complet de Scott Mitchell sur le site ASP.NET: http://www.asp.net/data-access/tatudials .
Quant à notre expérience jusqu'à présent, il a principalement été bon. Le concepteur de données génère une énorme quantité de code, même pour un petit nombre de tables (<20). Faire des changements dans les SproCs a causé quelques maux de tête, mais j'aimerais être montré un outil qui faciliterait cela.
Une chose que vous pourriez essayer de prendre votre décision plus facile: proposez un petit problème de domaine comme une page d'édition de client ou d'une page d'entrée de commande, puis de la mettre en œuvre plusieurs fois à l'aide d'une variété de technologies. Il faut du temps pour le faire, mais c'est un bon moyen d'apprendre et vous pouvez comparer les technologies pour vous-même. Nous avons fait cela et cela semblait aider beaucoup.