Puis-je utiliser Entity Framework avec un abonnement ASP.NET?

.net asp.net asp.net-membership entity-framework

Question

Je crée (vraiment, recrée) une application qui contient des données d'utilisateurs et autres données existantes dans des bases de données MS-Access. Les données seront déplacées vers SQL Server, ce qui implique notamment la migration des utilisateurs. Je souhaite utiliser EF pour effectuer des opérations ORM, et je suis presque certain de connaître le modèle de données dans SQL Server. Je suis nouveau sur EF, mais pas sur ASP.NET, et j'aimerais profiter des fonctionnalités d'adhésion dans ASP.NET. Je réfléchis à plusieurs façons de le faire et aimerais avoir des conseils. Je n'ai fait que peu de recherches sur cette idée jusqu'à présent, peut-être y a-t-il eu une réponse ailleurs. Donc, voici un groupe de questions connexes.

  1. EF peut-il travailler directement avec une adhésion ASP.NET via une classe ou un espace de noms que je ne connais pas?

  2. Si j'effectue une transition des utilisateurs vers le système d'appartenance, pour aligner leurs ID utilisateur sur les données d'autres tables, dois-je créer un autre ensemble de tables pour les données utilisateur au-dessus des tables aspnet_ * à la DotNetNuke?

  3. Je souhaite éviter une situation dans laquelle j'utilise les fonctions d'adhésion intégrées pour uniquement l'authentification de l'utilisateur et que je passe au contexte EF lorsque je travaille avec des données étiquetées par l'utilisateur. Cela semble maladroit de retirer les informations de l'utilisateur pour se lier à une colonne d'un GridView en allant dans un utilisateur d'appartenance pour chaque ligne, mais c'est peut-être ce qui est nécessaire? Dois-je l’utiliser et reproduire les classes d’appartenance dans EF à des fins de récupération de données?

  4. Je pensais peut-être mettre en place un type de fournisseur EF pour l'adhésion, sur l'idée que le fournisseur pourrait alors s'asseoir dans le modèle de données EF global. Est-ce une folle conversation? (Je n'ai jamais écrit mon propre fournisseur auparavant)

N'hésitez pas à me dire que je n'ai aucun sens.

Réponse acceptée

Pourquoi ne pas le faire dans l'autre sens? Vous pouvez implémenter votre propre fournisseur d'adhésion pour asp.net, qui utilise le modèle que vous souhaitez / dont vous avez besoin.

Si les fonctionnalités dont vous avez besoin ne correspondent pas parfaitement à l'implémentation d'adhésion asp.net intégrée, vous pouvez simplement lancer votre propre fournisseur. Si vous n'utilisez que quelques fonctionnalités, vous devrez implémenter quelques méthodes (vous n'avez pas à remplir l'implémentation pour toutes les méthodes). Si vous avez besoin de plus de fonctionnalités qu’il ne prend en charge, l’utilisation du fournisseur d’appartenance peut vous gêner.


Réponse populaire

  1. Nous le faisons, mais nous ne mappons pas les tables d'adhésion. Vous ne devriez pas supposer utiliser le fournisseur d'appartenance SQL.
  2. Nous mappons l'identité de l'utilisateur, pas l'identifiant de la base de données. Subtil, mais important. Encore une fois, rappelez-vous qu’il existe d’autres fournisseurs d’adhésion (par exemple, l’authentification de domaine).
  3. Pouvez-vous clarifier la question? Vous n'aurez pas besoin de répliquer toutes les informations d'adhésion dans votre modèle EF, mais vous aurez besoin d'une liste d'identités connues.
  4. Non, pas du tout fou, mais difficile et probablement inutile.


Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow