Pour un ERP de base (DB avec environ 150 tables, Winform App) qui s'exécuterait sur un réseau LAN classique (1 serveur et jusqu'à 25 clients) recommanderiez-vous EF4 ou DataSet?
linq2sql n'est pas une option!
4 Réponses :
ef4. DataSet est une ancienne technologie, EF est à bien des égards une réaction aux problèmes avec des ensembles de données.
Nous avons récemment construit une application, où une partie de celles-ci était des opérations de crud sur 80 tables. Avant EF, nous aurions utilisé la bibliothèque d'entreprises et les jeux de données. Nous aurions estimé 1 heure par table pour écrire l'opération CRUD et le test de l'unité. Avec EF, cela a été remplacé principalement avec du code autogénéré.
@Michael Maddox, oui, c'est en fait un test d'intégration car il frappe la base de données. Nous l'avons mis à l'intérieur d'une portée de transaction afin de ne pas changer la base de données. Fondamentalement, ils vérifient que personne ne modifie les scripts qui créent la base de données sans mettre à jour le modèle EF. Avec une première approche de code, cela serait un peu différent.
Combien d'enregistrements chargez-vous? Est-ce une option viable pour charger 20000 enregistrements (lignes) dans une grille avec cadre d'entité?
@threefouronesixonethree, vous devriez poser ceci comme une question
Vous pouvez choisir EF en fonction de la logique de l'application, EF peut vous donner plus d'options, mais je pense que nous ne pouvons pas décider en fonction du nombre de tables.
Vérifiez cet article qui vous aidera à décider:
Pourquoi utiliser le cadre d'entité?
Vérifiez également cette belle vidéo: Développement de données GPS: Conseils pour choisir la bonne technologie d'accès aux données pour votre application aujourd'hui
VideOlink est mort, allez ici pour un nouveau haut: canal9.msdn.com/events / Technique / Northamerica / 2010 / Dev324
C'est une question assez ouverte avec aucune information de soutien. Il y a une tonne de facteurs impliqués dans ce type de décision. Est-ce juste que vous développez ou une équipe? De toute façon, quelle expérience avez-vous avec EF? Si vous n'avez pas beaucoup d'expérience et qu'il y a une chronologie serrée, il peut être plus rapide d'obtenir le travail avec des jeux de données.
Ces types de questions à part, je suis un gros fan de l'ormes et je pense que cela facilite la vie à long terme. Mais il a une courbe d'apprentissage si vous ne connaissez pas certains des concepts et surtout les GOTCHAS (comme sélectionnez N + 1 numéros).
Il s'agit d'une application de bureau classique (plus OLPT / MOOP OLAP) avec la base de données MSSQL2008X dans le Backend (la majeure partie de la logique est construite dans des procédures et des relations stockées) sur les ventes, les achats, les commandes, les stocks, la production mais à petite échelle!
Même si vous ne choisissez pas EF4, les jeux de données ne sont pas la seule option.
Je aura beaucoup de travail avec Pocos que des jeux de données.
Les objets sont beaucoup plus faciles à manipuler que les jeux de données. Par exemple, la validation des données dans un POCO est triviale et facile à maintenir. Dans un jeu de données, il n'est ni ni.
Lorsque vous choisissez ces choses, nous devons connaître les exigences de performance et la manière dont les données sont stockées / exposées dans la DB .. Pouvez-vous partager un mot ou deux sur la structure de la table de performance et de DB?
Il s'agit d'une application de bureau classique (plus OLPT / MOOP OLAP) avec la base de données MSSQL2008X dans le Backend (la majeure partie de la logique est construite dans des procédures et des relations stockées) sur les ventes, les achats, les commandes, les stocks, la production mais à petite échelle!
Vous pouvez utiliser des procédures stockées avec EF4 - Carte SPS pour obtenir la création d'objets. Mais même si vous ne voulez pas utiliser EF4, je résisterais toujours à l'utilisation de jeux de données. Les objets sont beaucoup plus faciles à gérer.