[.NET] Probleem: ActiveRecord met statische connectionstring

[Verwijderd]

Ik probeer volgens de idee van ActiveRecord mijn classes te maken. Voor zover ik weet maak je 'finder' methodes statisch. Een vereiste van mijn webapplicatie is dat gebruikersgroepen hun eigen database hebben. Dus de finder methoden zijn overloaded om een database naam te krijgen. Na een toegangscontrole wordt dan eerst de connectionstring aangepast en vervolgens alsnog de 'gewone' finder methode aangeroepen.

Maar statische methoden gebruiken statische velden, en als ik eenmaal het statische veld connectionstring aangepast heb, dan geldt de waarde daarvan ook voor andere gebruikers!

Mijn vraag is nu:
Wie heeft een link naar een uitleg over het delen van static classes en velden, omdat ik het gedrag nu uit een paar tests zie, maar ik kan er geen uitleg over vinden.

[ Voor 3% gewijzigd door Verwijderd op 11-03-2007 20:31 ]

[MrBucket]

De meest nette manier lijkt me om de static connection string uit je classes te halen en in plaats daarvan deze als argument aan je static finder methodes mee te geven. Evt. kan je ipv een 'echte' connection string een class maken die de connection string encapsuleert, en deze als argument aan je finder methode meegeven.

[Verwijderd]

Zou je dat beter vinden dan de static finder methoden instance methoden te maken? En zo ja, waarom?

[MrBucket]

Als je elke find-methode een instance-methode maakt, dan neem ik aan dat je dat doet zodat je de connection string als member-variabele kan opslaan zodat je het niet als argument hoeft mee te geven.

Maar hoe doe je dan een find? Dan moet je eerst een nep ActiveRecord instantieren met de juiste connection string voordat je je query kunt uitvoeren. Dat lijkt me niet de bedoeling.

En realiseer je wel dat elk ActiveRecord dan zijn eigen connection string krijgt.

[Verwijderd]

Juist ja, dat is precies wat ik ook minder mooi vindt:

C#:

// Waarom een Customer maken om er meer te vinden (wie is die customer dan)?
Customer customer = new Customer();
CustomerList customers = customer.GetAll();

// Eventueel kan het ook nog zo, dan verberg je het een beetje, 
// maar dan kun je de instantie niet hergebruiken voor meerdere finds
CustomerList customers = new Customer().GetAll();

Wat wel kan is de finder methoden in finder classes zetten. Het is 'logischer' om een finder te instantieren en daarmee de objecten op te vragen. Maar dat doe ik nu (nog) niet.

Momenteel heb ik een basis class met een connectionstring en een extra constructor die de connectionstring aanpast:

C#:

public Customer(string database) : base(database) {}

Liever pass ik geen connectionstrings in, omdat het veranderen ervan nu in een private method in de basis class zit (netjes weggewerkt). De aanroeper hoeft alleen een string mee te geven aan de constructor (btw: waarom ondersteunt de ObjectDataSource geen constructor-parameters , was wel handig geweest ). Ik denk dat er dan niet genoeg reden is dit in een aparte class op te nemen.

[Verwijderd]

Als je de Castle Hibernate facility kan gebruiken voor je ActiveRecord, kun je wellicht de per-web-request lifecycle van je NHibernate session aanpassen om de connection string voor de huidige gebruiker te nemen.

[ Voor 24% gewijzigd door Verwijderd op 12-03-2007 07:21 ]

[Verwijderd]

Ik gebruik geen algemene software, ik volg alleen de idee van activerecord in mijn classes (voor zover mogelijk, want soms wil ik ook een class die niet direct 1-op-1 met een tabel overeenkomt).

Bedankt!