[ASP.NET] Berichten tonen op .aspx pagina's

[Jabbah]

Een beetje cryptische topic titel, maar het gaat om het volgende:

Ik heb een aantal aspx pagina's waarmee ik gegevens uit een database kan wijzigen, deleten of nieuwe gegevens toevoegen. De communicatie met de database wordt verzorgd via een aantal controller classes, een laag tussen de user interface en de database. Dit werkt allemaal naar behoren.

Wanneer ik een record in de database update, toevoeg of verwijder, wil ik dit graag melden aan de gebruiker. De index-pagina wordt dan opnieuw geladen met daarin de melding dat het updaten of whatever gelukt is. De controller classes die de communicatie met de database verzorgen hebben echter niet de Application scope. Ik kan hierin dus niet de global.asax of de session bereiken om mijn bericht in op te slaan.

Hoe kan ik hier het beste mee omgaan?

[gorgi_19]

* gorgi_19 snapt er niets van...

Je wilt dus iets hebben als

Visual Basic .NET:

Public Function UpdateRecords(melp as string) as StatusCode
 ...
End function

[Jabbah]

Hmm nee.. stel je voor:

code:

class DatabaseController
{
...
    public void UpdateTable(SomeClass myClass)
    {
        // Hier de code om de tabel te updaten

        string bericht = "The table was updated successfully.";
    }
...
}

In de code behind van mijn aspx pagina roep ik de methode UpdateTable() aan. Wanneer deze de database heeft geupdate wordt de aspx pagina (of een andere) opnieuw geladen met daarin een Label dat de tekst in de variable 'bericht' bevat.

De vraag is: Hoe krijg ik de waarde van de variabele 'bericht' in het Label? (De class DatabaseController heeft dus niet de Application of Session scope)

[Verwijderd]

zitten die classes wel in hetzelfde project of zijn het aparte assemblies? en waarom kan je geen property maken waaruit je die meldingen kan ophalen?

[gorgi_19]

Gewoon een returnwaarde geven?

zitten die classes wel in hetzelfde project of zijn het aparte assemblies? en waarom kan je geen property maken waaruit je die meldingen kan ophalen?

Maakt toch niet uit?

[ Voor 75% gewijzigd door gorgi_19 op 06-04-2004 09:52 ]

[Verwijderd]

als ze in dezelfde assembly zitten kan je toch gewoon httpcontext.current gebruiken of heb ik nou mis? en anders een return waarde, of de property opnemen, lijkt me niet zo moeilijk.

[gorgi_19]

Verwijderd schreef op 06 april 2004 @ 09:53:
als ze in dezelfde assembly zitten kan je toch gewoon httpcontext.current gebruiken of heb ik nou mis? en anders een return waarde, of de property opnemen, lijkt me niet zo moeilijk.

Ook als ze in een andere assembly zitten, kanje HttpContext.Current gaan benaderen. Puristisch gezien is dit alleen niet netjes, aangezien je je tiers gedeeltelijk gaat verklooien (je bindt jezelf vast aan webforms)

[Jabbah]

Wat betreft return waardes: Er zijn situaties waarin methode A methode B aanroept. Methode B roept dan weer methode C aan. Om nou het bericht helemaal door te sluizen naar methode A vind ik niet echt een mooie oplossing.

Wat betreft een property: De DatabaseController class is een static class. Het is puur een utility class en behoeft geen status. Indien nodig is het natuurlijk mogelijk om de class nonstatic te maken.

Alle objecten zitten in dezelfde assembly. Ik zal de MSDN er eens op naslaan wat betreft de HttpContext.Current.

[whoami]

Jabbah schreef op 06 april 2004 @ 10:02:

Alle objecten zitten in dezelfde assembly. Ik zal de MSDN er eens op naslaan wat betreft de HttpContext.Current.

Zoals gorgi_19 al zei, zou ik het niet zo oplossen. Op die manier bind je je nl. vast aan webforms. Die class kan je dan niet meer in een winform applicatie gaan gebruiken.
Het is beter dat je die string op de een of andere manier gewoon doorgeeft; dat je UI (in dit geval je webform) die class benaderd om die string te verkrijgen.
Zo moet het eigenlijk gaan: van je UI benader je een andere class om iets te verkrijgen en niet omgekeerd; die 'andere' class mag zelf niets te maken hebben met de UI, die class mag nl. niets afweten van de UI.

[Verwijderd]

Hoe zit je foutafhandeling in elkaar? Ik neem aan dat de database controler wel een of andere vorm van foutafhandeling bezit. Je wil een melding geven als alles goed is gegaan maar hoe merk je het als er iets fout gaat??

Het meest waarschijnlijke is dat er een Exception gegenereerd wordt als er dingen mis gaan. Ik kan niet in je code kijken maar ik neem aan dat je wel enige try catch contructies hebt rond het aanroepen van de UpdateTable functie.

Is het dan niet eenvoudig een kwestie van: Als er een exception optreed is er iets misgegaan en handel je de exception af (foutmelding aan de gebruiker, loggen of zoiets) en in alle andere gevallen is het dus goed gegaan en kan je dit melden aan de gebruiker. Hoeft je database controler dus verder helemaal niets te weten van je GUI hij moet alleen een exception gooien als er iets mis gaat.

[ Voor 12% gewijzigd door Verwijderd op 06-04-2004 10:22 ]

[gorgi_19]

whoami schreef op 06 april 2004 @ 10:08:
[...]


Zoals gorgi_19 al zei, zou ik het niet zo oplossen. Op die manier bind je je nl. vast aan webforms. Die class kan je dan niet meer in een winform applicatie gaan gebruiken.

Dat niet alleen, best kans dat je ook nog racing conditions krijgt en vars elkaar gaan overschrijven....

[gorgi_19]

Jabbah schreef op 06 april 2004 @ 10:02:
Wat betreft return waardes: Er zijn situaties waarin methode A methode B aanroept. Methode B roept dan weer methode C aan. Om nou het bericht helemaal door te sluizen naar methode A vind ik niet echt een mooie oplossing.

Waarom niet? Het lijkt me dat de status voor ieder onderdeel van belang is? En anders idd: als het fout gaat en het is afgelopen; exception gooien...

[Jabbah]

Heb even de HttpContect.Current bekeken. Dit is inderdaad niet wat ik wil. De controller class moet geheel onafhankelijk van de aspx blijven.

Ik ga de static classes vervangen door nonstatic classes, zodat ik ook een status kan bijhouden. De status bevat dan de melding en is ev. uitbreidbaar met andere informatie.

Uiteraard gebruik ik exception handling voor de toegang tot de database. Wanneer er een exception optreedt log ik deze in een tekstbestand. Ik overweeg nog om dit tekstbestand te vervangen door de Event Logger.
Wanneer een exception optreedt ga ik dezelfde status gebruiken om een duidelijke foutmelding aan de gebruiker te tonen, ipv een vage stacktrace.

[Jabbah]

gorgi_19 schreef op 06 april 2004 @ 10:26:
[...]

Waarom niet? Het lijkt me dat de status voor ieder onderdeel van belang is? En anders idd: als het fout gaat en het is afgelopen; exception gooien...

Het volgende vind ik niet echt mooi:

code:

string melding = controller.UpdateDatabase(myTable);

Maar dat zal wel een kwestie van voorkeur zijn.

[gorgi_19]

Jabbah schreef op 06 april 2004 @ 10:41:
[...]


Het volgende vind ik niet echt mooi:

code:

string melding = controller.UpdateDatabase(myTable);

Maar dat zal wel een kwestie van voorkeur zijn.

idd..
Maak een Enum met statuscodes aan en geef deze returnvalue terug.

Voor de rest het principe is het een kwestie van voorkeur.. Je kan evt. ook een Singleton class maken, gebaseerd op HttpContext, waarin je al je foutmeldingen dumpt. Enige nadeel zijn racing conditions, waar je goed voor uit moet kijken.