Har en (dll) applikation där endast en s.k facade klass ska vara synlig och tillgänglig utifrån. Under denna facade döljer sig olika subsystem (i enlighet med facade mönstret). Men hur döljer man dessa subsystem utåt? Miljön är VS.NET2003 och språket C#. När jag skapar en referens till dll:en i en webapplikation så poppar varenda klass upp i listan, vilket inte är meningen. Jag har provat att dela upp i namespace, men det får till följd att båda namespacen dyker upp i referenslistan. Om det går att dölja ett (det ena) namespace vore det en lösning... frågan är väl då hur.
Dölja subsystem
13 svar · 540 visningar · startad av PeW
Det är det accessnivåerna (private, public etc.) är till för. Endast det som du vill ska synas "utåt" ska vara public, resten (som inte är private, protected etc) får du sätta som internal. Dock måste man beakta att man inte på något sätt gör det omöjligt att köra de dolda metoderna utifrån (man kan exekvera vad som helst med Reflection), men de blir i alla fall dolda för VS.
"Internal" verkar vara det jag letar efter. Tack :)
"Dilemmat" är ju att jag inte kan sätta de i assemblyn, interna klasserna, till något annat än public. Förutom några enstaka singletons då.
PeW skrev:
"Internal" verkar vara det jag letar efter. Tack :)
"Dilemmat" är ju att jag inte kan sätta de i assemblyn, interna klasserna, till något annat än public. Förutom några enstaka singletons då.
Varför inte?
Dock måste man beakta att man inte på något sätt gör det omöjligt att köra de dolda metoderna utifrån (man kan exekvera vad som helst med Reflection), men de blir i alla fall dolda för VS.
Om jag inte har helt fel så kan du på klassen sätta säkerhets attribut som berättar vilka assemblys som har rätt att exekverar methoder i din assembly/dll-fil. Då kan du lösa problemet med reflections.
Inget som jag har bekräftat bara hört av en kollega, samt att jag är ganska övertygad att MS har sätt till så att man inte skall kunna köra kod som man inte bör kunna köra genom ett så enkelt hack som reflections...
- M
Gladh skrev:
Dock måste man beakta att man inte på något sätt gör det omöjligt att köra de dolda metoderna utifrån (man kan exekvera vad som helst med Reflection), men de blir i alla fall dolda för VS.
Om jag inte har helt fel så kan du på klassen sätta säkerhets attribut som berättar vilka assemblys som har rätt att exekverar methoder i din assembly/dll-fil. Då kan du lösa problemet med reflections.
Inget som jag har bekräftat bara hört av en kollega, samt att jag är ganska övertygad att MS har sätt till så att man inte skall kunna köra kod som man inte bör kunna köra genom ett så enkelt hack som reflections...
- M
Riktigt så enkelt är det inte. De attribut man kan sätta (t.ex. StrongNameIdentityPermission) hjälper till att hindra att "gömda" metoder körs av misstag, men om man verkligen vill jävlas så stänger man bara av CAS (SecurityManager.SecurityEnabled=false), så ignoreras attributet. Lösningen är att metoderna får kontrollera specifikt vem som anropar (och kontrollera att SecurityManager.SecurityEnabled==true). Inte snyggt, men möjligt.
emission skrev:
Varför inte?
Därför att private inte medger åtkomst och inte ska det heller ;) Det rör sig om ett tjog klasser i varsina filer som utgör den logik som facade representerar med valda metoder. Allt enligt GOF.
Aha. Då var det ju inget problem.
Jo, problemet var att vid addning av referens till dll:en så dök varenda klass upp i listan och det vill jag förhindra ;)
Okej, då är jag tillbaka i frågeteckenläge... :)
Det finns ingen anledning att göra en klass till public om den inte ska synas utåt.
hmm.. de ska ju synas utåt till de andra klasserna i applikationen, men inte utanför själva applikationen. Där ska endast facade klassen samt någon till synas.
hmm.. de ska ju synas utåt till de andra klasserna i applikationen, men inte utanför själva applikationen. Där ska endast facade klassen samt någon till synas.
Du kan inte göra en metod Applikations specifik, du kan antingen gör den specifik för din assembly (internal) eller helt publik (public). Tyvärr finns ingen "ApplicationPublic", har själv önskat det någon gång men så är läget, gilla det... :)
Du får helt enkelt tänk om vilka klasser som skall placeras i vilka projekt så du kan sätta Internal på dem som endast skall kunna ses mellan de olika klasserna.
- M
Lösningen är att metoderna får kontrollera specifikt vem som anropar (och kontrollera att SecurityManager.SecurityEnabled==true). Inte snyggt, men möjligt.
Du kan fortfarande låta attributet sitta kvar, men bara kontrollera om SecurityEnabled är satt, om den inte är det så kastar man ett fel tillbaka som kräver att den är enabled.
På det sättet så slipper du kontrollera vem som kallar dig, men bara kontrollera om security är enabled. Det är däremot riktigt störigt att man måste göra den kontrollen i varje metod och att man inte kan sätta ett attribute som kräver att CAS är aktiverad annars så körs inte koden....
- M
Gladh skrev:
Du kan fortfarande låta attributet sitta kvar, men bara kontrollera om SecurityEnabled är satt, om den inte är det så kastar man ett fel tillbaka som kräver att den är enabled.
Jo, attributet måste sitta kvar. Fick för mig att jag läst någonstans att det gick att kringgå på ett ännu djupare plan, men jag kan inte hitta det så jag har kanske drömt.
Gladh skrev:
Det är däremot riktigt störigt att man måste göra den kontrollen i varje metod och att man inte kan sätta ett attribute som kräver att CAS är aktiverad annars så körs inte koden....
Precis!