[VB.NET] Hoe Connectionstring alleen te zien in DLL

[Verwijderd]

Hoi,

Mijn 1e post, hele FAQ doorgelezen dus hopelijk is mijn 1e post in orde

Ik heb gezocht op google maar kon niks vinden en op de search van tweakers ook niks gevonden.

Ik ben een DLL aan het maken in VB.NET met daarin een soort mapping van objecten en hun data met een SQL SERVER 2000 database.

De DLL wil ik in meerdere programma's gaan gebruiken zodat ik niet iedere keer objecten zoals gebruiker, waar ze werken etc hoef te programmeren en de afhandeling met de database.

Werkt allemaal prima. Alleen in de DLL heb ik de connectionstring opgeslagen in een klasse met een get property zodat ik die in bijvoorbeeld de klasse gebruiker weer kan gebruiken voor de connectie met de database.

Nadeel is als ik de DLL import in een programma dat hem gebruikt dat ik niet alleen het object user uit de DLL kan gebruiken maar ook de connectionstring van de database kan opvragen.

Hoe kan ik er voorzorgen dat ik binnen de gehele DLL de connectionstring kan zien en gebruiken, maar dat niet door een programma dat de DLL gebruikt?

[Verwijderd]

Declareer de connectionstring property als "internal" nu kan alleen de namespace van je module de property zien, de anderen niet.

(Zoek op internal access-level in MSDN)

have fun!

[Verwijderd]

Ik maak gebruik van namespaces

Visual Basic .NET:

Namespace Bedrijf
  
   class gebruiker

   class regio

    namespace Dataclient

       class sqlconnection

   end namespace

end namespace

Met internal zou ik dus geen gebruik kunnen maken van de property die ik met interna declareer in de class gebruiker en de class regio

[whoami]

Nee, dat klopt. Internal zorgt ervoor dat je property enkel zichtbaar / toegankelijk is vanuit de Dataclient namespace.

Waarom zet je die connectionstring eigenlijk niet in een config-file ? Nu moet je je DLL hercompileren als je connectionstring veranderd.
Ik snap ook niet waarom je Dataclient namespace genest is in Bedrijf.

[EfBe]

internal is per assembly, niet per namespace. VB.NET heeft overigens het illustere keyword 'friend' dat je moet gebruiken, niet 'internal'.

Ik zou echter doen wat whoami zegt, je connection string in een config file zetten. Die inlezen kost 1 keer 200ms geloof ik gemiddeld en daarna bijna niks.

[Verwijderd]

Ja config file klinkt ook goed.

Maar als er veel gebruik gemaakt wordt van de database dan is het wel, "significant" trager dan de connstring opnemen in de DLL toch?

Plus dat ik dan met encryptie moet gaan werken omdat de config file dan met de DLL en applicaties die hem gebruiker verspreidt moet worden.

[Verwijderd]

whoami schreef op 21 april 2004 @ 13:11:

Ik snap ook niet waarom je Dataclient namespace genest is in Bedrijf.

Ja is keuze.

Bedrijf.Gebruiker

Bedrijf.Regio

Bedrijf.Dataclient.SQL
Bedrijf.Dataclient.Access
Bedrijs.Dataclient.SAP

Op deze manier wil ik dus de databronnen van het bedrijf implementeren.

[whoami]

Verwijderd schreef op 21 april 2004 @ 13:20:
Ja config file klinkt ook goed.

Maar als er veel gebruik gemaakt wordt van de database dan is het wel, "significant" trager dan de connstring opnemen in de DLL toch?

Voor zover ik weet en me nog kan herinneren zou een config.file volledig in het geheugen geladen worden. Pas als er iets veranderd aan die config file wordt hij 'herladen'.
Dat zal dus best niet zo traag zijn als je denkt.

Plus dat ik dan met encryptie moet gaan werken omdat de config file dan met de DLL en applicaties die hem gebruiker verspreidt moet worden.

Waarom? Zolang je geen paswoorden / gebruikersnamen in die connection-string opneemt, is er toch geen probleem?

[Verwijderd]

whoami schreef op 21 april 2004 @ 13:24:


Waarom? Zolang je geen paswoorden / gebruikersnamen in die connection-string opneemt, is er toch geen probleem?

Wij zitten in een omgeving Netware omgeving, geen Active Directory. Dus elke connectiestring van de SQL Database moet voorzien van een username/password. Of ik moet er goed naast zitten. Trusted kan niet voor zo ver mijn kennis reikt.

[pjvandesande]

Verwijderd schreef op 21 april 2004 @ 13:32:
[...]


Wij zitten in een omgeving Netware omgeving, geen Active Directory. Dus elke connectiestring van de SQL Database moet voorzien van een username/password. Of ik moet er goed naast zitten. Trusted kan niet voor zo ver mijn kennis reikt.

Je kan er opzich ook gewoon een standaart encryptie overheen donderen.

[whoami]

Ik zou dan gewoon m'n connectie-string encrypten, en niet de volledige file.

Hou er ook rekening mee dat, als je je connection-string niet ge-encrypteerd in je executable, deze ook eenvoudig te achterhalen is. Als je je assembly opent mbhv een hex-editor, dan vind je die connectiestring makkelijk terug.

[Verwijderd]

questa schreef op 21 april 2004 @ 13:34:
[...]


Je kan er opzich ook gewoon een standaart encryptie overheen donderen.

Ja dat kan, maar dan moet ik dus iedere keer een decrypt actie doen in mijn DLL.

[Creepy]

Verwijderd schreef op 21 april 2004 @ 13:38:
[...]


Ja dat kan, maar dan moet ik dus iedere keer een decrypt actie doen in mijn DLL.

Eenmalig tijdens het laden van je DLL, of als het bestand weer is verandert, of bij het openen van een DB connectie. Lijkt me nou niet dat dat een bottleneck is.

Of open je voor elke query opnieuw een connectie naar de DB?

[ Voor 15% gewijzigd door Creepy op 21-04-2004 13:45 ]

[Verwijderd]

Creepy schreef op 21 april 2004 @ 13:43:
[...]

Eenmalig tijdens het laden van je DLL, of als het bestand weer is verandert. Lijkt me nou niet dat dat een bottleneck is.

Als ik de connectiestring nodig heb dan moet hij iedere keer gedecrypt worden.

Voor zover ik weet is er geen assembly te maken met een function OnLoad oid.

Dus lijkt mij dat ik de DLL wel iedere keer de decrypt actie moet doen omdat ik de connectiestring sporadisch gebruikt wordt.

Of open je voor elke query opnieuw een connectie naar de DB?

Wil gebruik gaan maken van een connectionpool.

[ Voor 13% gewijzigd door Verwijderd op 21-04-2004 13:49 ]