Berichten: 39.538
Reg. datum: 26 december 2000
Reg. datum: 26 december 2000
need more info ....
Wat bedoel je met 'slechts bepaalde data zien' ? Gaat dit over bepaalde records die hij al of niet mag zien, of gaat het over bepaalde velden die hij wel of niet mag zien, of een combinatie ?
Wat bedoel je met 'slechts bepaalde data zien' ? Gaat dit over bepaalde records die hij al of niet mag zien, of gaat het over bepaalde velden die hij wel of niet mag zien, of een combinatie ?
het gaat om rijenquote:whoami schreef op donderdag 03 juli 2008 @ 12:41:
need more info ....
Wat bedoel je met 'slechts bepaalde data zien' ? Gaat dit over bepaalde records die hij al of niet mag zien, of gaat het over bepaalde velden die hij wel of niet mag zien, of een combinatie ?
er zijn 3 tabellen, zegge A, B en C met ieders een 1 op n relatie:
daarnaast zijn er configuratietabellen. In deze config tabellen wordt bepaald welke gebruiker welke rijen uit A B en C mag zien.
Dus als je gaat joinen, krijg je in je resultaatset te kolommen: UserId, Entiteit1, Entiteit2,Entiteit3,..., AllowedUserRole te zien?
Dan kan je toch een WHERE clausule gebruiken?
Dan kan je toch een WHERE clausule gebruiken?
Managementgame en managementsimulatie, spelenderwijs leren
Ga je die views gewoon plat naar de gebruiker gooien of vertaal je de resultaten ook nog eens naar objecten?
Checked out bij someone else in another place
De Laatste Der Mondharmonikanen
Berichten: 39.538
Reg. datum: 26 december 2000
Reg. datum: 26 december 2000
* whoami snapt ook niet wat het probleem / moeilijkheid nu precies is ?quote:gorgi_19 schreef op vrijdag 04 juli 2008 @ 10:03:
Dus als je gaat joinen, krijg je in je resultaatset te kolommen: UserId, Entiteit1, Entiteit2,Entiteit3,..., AllowedUserRole te zien?
Dan kan je toch een WHERE clausule gebruiken?
Aangezien je het ID van de user kent, kan je toch idd gewoon filteren mbhv where ?
ik zat me af te vragen hoe de public API er uit zou kunnen zien voor zo'n DAC.quote:whoami schreef op vrijdag 04 juli 2008 @ 11:57:
[...]
* whoami snapt ook niet wat het probleem / moeilijkheid nu precies is ?
Aangezien je het ID van de user kent, kan je toch idd gewoon filteren mbhv where ?
stel: MyDataDAC class
public static MyCustomList GetMyCustomList(param1, param 2, etc.....)
{
}
Ik zit nog te stoeien met de API. Ik denk dat de public methods geen elementen van de user moet hebben, dit zou ik graag willen zien in de constructor. De user ID kan ik dan opslaan als member op de DAC. Elke method kan dan de user ID raadplegen voor de filtering. Het nadeel hier van is dat de DAC zelf niet meer static kan zijn. Wil ik dat wel dan vervuil ik elke method met user ID zaken.
ps: ik weet nu nog niet hoe ik de user ID kan opbouwen, weet nog te weinig van de environment (bij een AD kan ik de Windows Identity gebruiken, maar zo niet dan een custom identity), vandaar even mijn vraagteken over het juiste type van UserID.
Je hebt het over stored procedures. Ik zou eerst wel eens willen zien hoe jij de userid gaat checken in die stored procs, nl. via de credentials op de active connection of middels gewone parameters. Want indien het 1e, dan kun je middels connections gewoon security regelen, en indien 2 dan is het gewoon een where clause.
Ook is het anno 2008 IMHO gewoon tijdverknoeien om je nog bezig te houden met het schrijven van een DAL, die zijn er genoeg.
Ook is het anno 2008 IMHO gewoon tijdverknoeien om je nog bezig te houden met het schrijven van een DAL, die zijn er genoeg.
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog
Microsoft MVP (C#). PSN ID: EfBe
Pagina: 1
