Ciao a tutti,
sto progettando una nuova applicazione che sarà organizzata secono il three layered application pattern con relativi strati Data Access, Business e Presentation.

Per il presentation layer utilizzerò ASP.NET e vorrei poter utilizzare la gestione di membership e roles offerte dal Framework con un'autenticazione di tipo form. Sarebbe ottimo poter utilizzare SqlMembershipProvider il SqlRoleManagerProvider.

A questo punto però ho dei problemi architetturali perchè le informazioni sull'utente dell'applicazione fanno parte anche degli oggetti "business" veri e propri da gestire e da mettere in relazione con altre informazioni.

Se gestissi gli utenti solo con i provider standard queste informazioni sarebbero presenti solo sul presentation layer e inutilizzabili dai livelli sottostanti.

Le possibili soluzioni che ho individuato sono:

- implementare dei provider custom che poggino sul business e sul data access layer

- implementare l'oggetto business "utente" (e relativi metodi di accesso alla base dati nel DAL) duplicandolo rispetto all'utenza di ASP.NET vera e propria, facendo cura di gestire in fase di creazione e modifica degli utenti la relazione tra i due oggetti separati

La prima soluzione probabilmente è architetturalmente più pulita ma a mio parere costosa.
La seconda mi permetterebbe di ri-utilizzare le librerie già disponibili con il costo di una complessità e criticità maggiore nelle fasi di creazione e modifica delle utenze.

Apprezzerei qualche opinione al proposito.

Grazie
Roberto

A questo punto però ho dei problemi architetturali perchè le informazioni sull'utente dell'applicazione fanno parte anche degli oggetti "business" veri e propri da gestire e da mettere in relazione con altre informazioni.

Se gestissi gli utenti solo con i provider standard queste informazioni sarebbero presenti solo sul presentation layer e inutilizzabili dai livelli sottostanti.

assolutamente no, attraverso le Role e Memebership API puoi utilizzarle a qualsiasi liverllo

se successivamente hai necessità particolari pui estendere i provider esistenti ma le API rimaranno immutate

ciao marco

Appoggio quello che ha detto Marco, in una applicazione un pochino più 'progettata' abbiamo incapsulato Membership e Profile nello stratto di business, (Role invece non era all'altezza delle aspettative del cliente ), ho scritto due appunti su come ho fatto qui: http://blogs.aspitalia.com/novecento/post1934/Usato-Membership-API--Co.aspx, magari una lettura ti può aiutare a scegliere.

Ciao a tutti,
sono state utilissime tutte le risposte e l'articolo scritto da Alessio
.
Effettivamente i dubbi esposti da Vladimiro sull'integrazione delle tabelle aspnet con quelle del db originale sono anche i miei, specialmente per quanto riguarda le relazioni tra gli oggetti che dovrò implementare. Queste differenze tra l'altro si propagherebbero sugli oggetti a livello DAL e business.

Ho scaricato e dato un'occhiata ai sorgenti dei provider Sql di Microsoft, e riletto l'articolo di Alessio e penso che utilizzerò entrambi come spunto per costruire dei provider custom che non utilizzino direttamente il DB ma utilizzino lo strato business e sottostante DAL, di modo da mantenere omogenea la struttura dell'applicazione. Magari implementando a livello business le regole per l'autenticazione.

Così ad occhio mi sembra che con 3-4 giorni di lavoro si possano realizzare i provider.
Se pensate che invece mi stia infilando in un ginepraio non esitate a farmelo sapere.

Grazie Mille