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
