Salve a tutti,

leggendo in msdn (http://msdn2.microsoft.com/en-us/library/system.web.profile.aspx ) apprendo che all'inizio dell'applicazione, asp.net crea "al volo" una nuova classe ProfileCommon , ereditando da ProfileBase.

Questa fantomatica classe ProfileCommon espone accessòri alle proprietà per ogni tipo definito nella relativa sezione di configurazione.

Con somma gioia apprendo anche che una istanza della classe ProfileCommon valorizza la proprietà Profile di HttpContext corrente.

benissimo.

Ma come posso accedere a questo oggetto ad un livello, diggiamo, "diverso" dalla stretta applicazione web come, ad esempio, una libreria esterna?

Quest'idea bislacca mi è venuta pensando di farmi una mia classe "UserBusiness" che fondesse alcune informazioni Membership a quelle Profile ed anche alcuni metodi per giocare con ObjectDataSource, una specie di classe "wrapper" tra i vari provider.

Cerdo di spiegarmi meglio, attraverso il blog del "capo" (http://weblogs.asp.net/scottgu) apprendo un link ad un interessantissimo articolo (http://peterkellner.net/?p=24) relativo all'uso reale di MembershipProvider attraverso ObjectDataSource, i dettagli li potete leggere nell'articolo, la chiave interessante è la creazione appunto di una classe "wrapper" tra il MembershipProvider e ObjectDataSource; è ovvio per me che , definita cosa buona e giusta registrare codice fiscale e dna dell'utente dentro Profile, se voglio estendere realmente la gestione utente e portarla ad un livello vendibile, devo per forza fondere le due logiche , e quindi callback alla domanda iniziale: come accedo a ProfileCommon ?

ma ha senso pensare di fare questa attività oppure sto facendo fanta.net ?

buona serata a tutti

grazie per la risposta,

riflettendo un po' penso che l'uso di Profile come contenitore di informazioni utente "personali" sia una forzatura; la spia potrebbe farcela il fatto che microsoft abbia inserito una proprietà ProfileBase Profile nell' HttpContext della richiesta corrente proprio per dire: signori, quando l'utente entra (login o meno) e si modifica colori ed altre impostazioni [webparts ecc.. (windows mail , Live rulez)] voi registrate 'ste cose nel Profile, così noi ve le mettiamo nel contesto, sempre li a portata di mano;

è quindi automatico [per me (in questo momento)] escludere cognome o codice fiscale da queste informazioni "trascinate" nell' HttpContext , a vantaggio invece di informazioni più "volatili", ad esempio, oggetto d'uso al layout.

infatti forse il mio errore era quello di voler "condizionare" l'istanza di una classe in funzione di una informazione "Profile" [per la serie, se hai un cognome che comincia per "s" ti valorizzo una proprietà con true (es.)] .

e quindi, concludo che informazioni "personali" debbano finire dentro una estensione di MembershipUser trattandosi di informazioni "utente", mentre abitudini e personalizzazioni vengano collocate in Profile trattandosi di informazioni "volatili" che , tutto sommato, se registriamo su db, facciamo solo un gran favore all'utente

confutatemi, please

Bene, per la cronaca dopo un po' di studio posso dire che la confutazione viene dalla possibilità di poter impostare le proprietà di Profile non solo come nodi nel web config (<profile><properties><add ..) ma anche con una classe che erediti da ProfileBase, dichiarando l'attributo inherits="MYUserProfile" nel nodo <profile> .

Tuttavia per avere la possibilità di accedere all'istanza "Profile" anche al di fuori del contesto "sito" , cioè ad esempio in una classe esterna (il mio obiettivo "principale" era infatti fare una classe di appoggio ad un ObjectDataSource e che quindi facesse da wrapper tra Membership e Profile) è necessario scrivere in MYUserProfile un metodo che acceda e istanzi il "profile provider" :


/// <summary>
/// Costruisce un oggetto MyUserProfile in base all'Username dell'utente
/// metodo internal per uso esclusivo della classe wrapper UserWrapper
/// </summary>
/// <param name="_pUsername"></param>
/// <returns></returns>
internal MyUserProfile GetProfileInternal(string _pUsername)
{
return ((MyUserProfile)(ProfileBase.Create(_pUsername)));
}

ok , invenzione dell'acqua calda, è bastato sbirciare nella famigerata classe ProfileCommon generata runtime ... il punto è proprio questo : nel contesto "sito" Profile stesso si appoggia alla propria ProfileCommon , noi nel contesto classe wrapper ci appoggiamo alla nostra MyUserProfile .

il funzionamento mi sembra corretto, sul principio ho ancora gli stessi dubbi dei precedenti post, tuttavia ho due domande in più:

- cosa ne pensate?

- quando facciamo Profile.GetProfile(_UserName) asp.net si appoggia al GetProfile( di ProfileCommon , passando quindi da ProfileBase che "ne deduco" sia lui il reale "manager" di ProfileProvider, ma allora la parola magica Profile. , da dove spunta?

buon lavoro