Domanda

Sto creando (davvero, ricreando) un'app che ha utenti esistenti e altri dati nei database MS-Access. I dati verranno spostati su SQL Server e parte di ciò comporta la migrazione degli utenti. Voglio usare EF per fare ORM e sono abbastanza sicuro di sapere quale sarà il modello di dati in SQL Server. Sono nuovo di EF ma non di ASP.NET e vorrei sfruttare le funzionalità di iscrizione in ASP.NET. Sto pensando a diversi modi per farlo e vorrei un consiglio. Finora ho fatto solo una piccola ricerca su questa idea, forse è stata data risposta altrove. Quindi, ecco un gruppo di domande correlate.

  1. EF può funzionare direttamente con l'iscrizione ASP.NET attraverso una classe o uno spazio dei nomi di cui non sono a conoscenza?

  2. Se passo gli utenti al sistema di appartenenza, per allineare i loro userid ai dati in altre tabelle dovrei creare un altro set di tabelle per i dati degli utenti in cima alle tabelle aspnet_ * alla DotNetNuke?

  3. Voglio evitare una situazione in cui utilizzo le funzioni di appartenenza integrate solo per l'autenticazione dell'utente e passo al contesto EF quando lavoro con i dati con tag utente. Sembra goffo ritirare le informazioni dell'utente per collegarsi a una colonna in un GridView andando in un utente di appartenenza per ogni riga, ma forse è quello che è necessario? Devo risucchiarlo e replicare le classi di appartenenza in EF ai fini del recupero dei dati?

  4. Stavo pensando di implementare forse un qualche tipo di fornitore EF per l'iscrizione, sull'idea che forse allora il fornitore potrebbe sedere all'interno del modello globale di dati EF. È un discorso folle? (Non ho mai scritto il mio provider prima)

Sentiti libero di dirmi che non ho alcun senso.

È stato utile?

Soluzione

Perché non farlo al contrario? È possibile implementare il proprio provider di appartenenze per asp.net, che utilizza il modello desiderato / necessario.

Se le funzionalità di cui hai bisogno non sono una corrispondenza completa con l'implementazione dell'iscrizione asp.net integrata, puoi semplicemente creare il tuo provider. Se utilizzerai solo un paio di funzioni, dovrai implementare solo un paio di metodi (non devi compilare l'implementazione per tutti i metodi). Se hai bisogno di più funzionalità di quelle supportate, l'utilizzo del provider di appartenenze potrebbe ostacolarti.

Altri suggerimenti

  1. Sì, ma non mappiamo le tabelle di appartenenza. Non dovresti presumere l'uso del provider di appartenenze SQL.
  2. Mappiamo l'identità dell'utente, non l'id DB. Sottile, ma importante. Ancora una volta, ricorda che ci sono altri provider di appartenenza (ad es., Autenticazione di dominio).
  3. Puoi chiarire la domanda? Non dovrai replicare tutte le informazioni sull'iscrizione nel tuo modello EF, ma avrai bisogno di un elenco di identità conosciute.
  4. No, per niente pazzo, ma difficile e probabilmente non necessario.
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top