Går det att membershipprovidern ärver min User klass?
MemberShipProvidern, ProfileProvidern och allt det är kalas men extremt dumt egentligen. Förstår inte varför de inte kunde ta hänsyn till n-tier designen ens i asp.net 3.5.
Jag kan ju inte ärva från ProfileCommon men jag kan jag göra tvärtom?
Vad vill du åstakomma, att kalla något som bygger på provider modellen för extremt dumt är väll inte så smart :) Varför vill du att den ska ärva från din klass, providermodellen bygger ju på att du ska implementera egna providers om inte de som finns med passar.
Går det att membershipprovidern ärver min User klass?
MemberShipProvidern, ProfileProvidern och allt det är kalas men extremt dumt egentligen. Förstår inte varför de inte kunde ta hänsyn till n-tier designen ens i asp.net 3.5.
Jag kan ju inte ärva från ProfileCommon men jag kan jag göra tvärtom?
Bygg en egen custom membershipprovider som ärver membershipprovider och en egen custom membershipUser som ärver membershipuser så kan du använda dina egna databaser och tabeller.
Oavsett hur jag vrider och vänder på det så är providern långt ifrån en färdig lösning och det jag skulle behöva använda den till är egentligen bara att skapa en inloggning och hålla reda på den. Kan ju lika gärna
HttpCookie cookie = new httpCoockie
Om inte det går skapa en session.
Jag tror att det blir enklare trots allt. Även när det gäller roller så måste det ju gå snabbare att jämföra en cookie.Permissions mot en enum än att hela tiden hämta från databasen.
Dessutom tycker jag inte om att ha allting som värdepar i databasen och behöva loopa / göra flera hämtningar. Då måste tableprovidern vara bättre men även där innebär det att skriva om precis allt så jag tror jag låter bli providern.
Det är ju inga problem att köra över providern men är ju.... onödigt ;)
269 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
