Entity framework vs enterprise library

Question

Je travaille sur un projet asp.net, le client m'a donné accès à une base de données à distance.

La base de données a deux utilisateurs. Un utilisateur a un accès en lecture seule alors que l'autre a un accès propriétaire. Le client dit que pour les besoins de lecture de données, nous devrions utiliser le premier et pour l'insertion, etc., utiliser le second.

Aussi le client m'a dit d'utiliser autant que possible les procédures stockées car il y a beaucoup de données qui proviendront du serveur db. Je veux utiliser le framework Entity (edmx). Puis-je utiliser des procédures stockées avec? Avant la structure Entity, j'ai utilisé la bibliothèque Enterprise pour les procédures stockées. Ai-je besoin de revenir en arrière et de l'utiliser avec des procédures stockées pour que tout le travail lié à la base de données se fasse sur le serveur db au lieu d'apporter des données au serveur web en utilisant le framework d'entité?

De même, comment puis-je utiliser un utilisateur à des fins de lecture seule et un autre utilisateur pour accéder à la même base de données pour l'insertion? Ai-je besoin de créer deux configurations Web? Est-ce que cela fait une différence de rendre un utilisateur uniquement en lecture et d'obtenir des résultats plus rapidement?

S'il y a une meilleure approche alors s'il vous plaît me suggérer.

Veuillez nous suggérer.

Answer 1

Vous pouvez utiliser des procédures stockées avec EF. Mais attention, il est vraiment difficile de faire fonctionner les entités avec des procédures stockées.

EF génère des requêtes sans écrire d'instructions SQL, il génère des instructions SQL en observant les changements dans les entités. Il ne fait que mapper vos entités aux tables db. Donc, si vous avez une table nommée "Item", elle crée un objet "Item" du côté du code. Vous pouvez créer une entité "Item" à l'aide du code et des méthodes associées à l'appel de EF pour refléter les modifications effectuées dans l'entité par rapport à la base de données.

Vous pouvez créer la chaîne de connexion de manière dynamique en fonction de l'action.

La question est trop large, donc je ne sais pas si cela aide.

Answer 2

Entity Framework ne se produit pas côté serveur. Il génère une requête sql et la requête s'exécute sur la base de données. Les résultats mis en correspondance avec un ou plusieurs objets par ef. C'est ce qu'on appelle un ORM. Google devrait avoir beaucoup d'informations sur ORMS.

Blair

Answer 3

Demandez-lui quel avantage il sent qu'il obtient en ayant vous ne lisez accès par un utilisateur et d'insérer un accès par l'autre et s'il a une raison légitime alors assurez-vous juste qu'il sait qu'il fait un compromis entre dans en ce qui concerne l'augmentation du temps de développement et de maintenance.

Deuxièmement, qu'est-ce que l'utilisation des procédures stockées a à voir avec la quantité de données? Si vous effectuez un volume élevé de requêtes (probablement pas si vous extrayez des tonnes de données), vous pouvez réduire légèrement le trafic réseau en utilisant des procédures stockées simplement parce que la demande de déclenchement d'un proc stocké sera inférieure à une requête chaîne. Cela ne vaut même pas la peine de s'inquiéter.

Jeff Atwood a fait quelques grands commentaires sur procs stockés ici: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

et ici: http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql.html

En général, quand les gens veulent limiter les développeurs à utiliser procs stockés ce soit pour les avantages perçus qui ne sont pas réel, et ils ne réalisent pas qu'ils ralentissent le développement sans raison valable. Non pas que les procs stockés soient mauvais, mais ils ont leur place et cela n'a tout simplement pas de sens d'avoir une règle qui dit qu'ils devraient être utilisés le plus largement possible.