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

Question

Je crée (en réalité, une re-création) 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 en partie 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 a-t-on déjà répondu ailleurs. Alors, voici un groupe de questions connexes.

1. EF peut-il travailler directement avec l'appartenance à ASP.NET par le biais d'une classe ou d'un espace de noms inconnu?

2. Si j'effectue la 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 que les fonctions d'adhésion intégrées ne soient utilisées que pour 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 à l'intérieur du 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.

Answer 1

Pourquoi ne pas le faire à l’inverse? Vous pouvez implémenter votre propre fournisseur d'adhésion pour asp.net, qui utilise le modèle que vous souhaitez / 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, le fournisseur d’appartenance risque de vous gêner.

Answer 2

1. Nous le faisons, mais nous ne mappons pas les tables d'adhésion. Ne présumez pas utiliser le fournisseur d'appartenance SQL.
2. Nous mappons l'identité de l'utilisateur, pas l'ID de la base de données. Subtil, mais important. De nouveau, 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 sur les membres 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.