[ASP] Is dit een efficiente pagina?

[blijhoofd_bennie]

Ik was een bezig een pagina aan het maken (voor stagebedrijf). Dit wordt een ASP pagina. Na wat informatie verzameld te hebben kwam ik tot de volgende ideeen hoe "goede" pagina gemaakt kan worden (database ontwerp komt nog). Graag wilde ik jullie meeningen, ervaring etc hierover horen.

Mijn ideeen:

1)
Functions overal voor gebruiken, dus voor checks (logisch) maar ook voor het invoeren van gegevens in de database. Bij dit laatste vroeg ik me af of dit een vaak gebruikte methode was?

De voordelen (volgens mij) door overal functies te gebruiken:
Er zit een extra "laag" tussen de gegevens zit (dus betere beveiling van de gegevens) en de uiteindelijke invoeractie. De code kan allemaal op 1 pagina worden gezet (include).
Ik hoef alleen de function in de andere pagina aan te roepen om gegevens in te voeren.
Fouten zijn makkelijk op te sporen.
Ik hoef dezelfde code niet vaker te typen of ietsjes aan te passen.

Opmerking:

Functions worden (naar mijn weten) veelal gebruikt om checks uit te voeren, maar worden ze ook gebruikt om data in de database in te voeren? (dus de insert/delete in een function). Is dit een goede aanpak of is dit onnodig? Wordt de page hier langzamer van of vreet dit teveel resources op de server? (of andere gevolgen die mij niet te binnen schieten maar jullie wel).
Het idee om functions te gebruiken komt van de stored procedures die er in SQL zitten, aagezien er (nog) gebruikt wordt gemaakt van een Access 2000 database is deze optie nog niet aanwezig.

2)
Zoveel mogelijk dezelfde pagina's te gebruiken. Als er nieuwe menu's toegevoegd worden aan het bezoekers deel van de pagina of beheers gedeelte van de pagina, zijn deze schermen (kwa uiterlijk) bijna identiek (de beheerspagina heeft een paar extra opties). Is het in dit geval dan niet handig om 1 pagina te maken en bijvoorbeeld afhankelijk van de gebruiker id de extra velden weer te geven en andere functies te gebruiken etc?

Opmerking:
Mijn persoonlijke ervaring zegt mij dat dit een programmeer omgeving zoals VB of delphi een hele goede manier zou zijn, omdat het hier geen scripting taal betreft en daardoor voordelen bied kwa snelheid en uitvoer etc (hier ga ik verder ff niet dieper op in).
Maar is dit een gangbare manier van werken op het internet.
Is deze manier bijvoorbeeld wel snel genoeg? of zou het gewoon sneller zijn 2 pagina's (of meerdere) te maken die bijna hetzelfde zijn?

Voordelen:
Het programmeer gedeelte wordt hierdoor een stuk kleiner en overzichtelijker. Ook wordt het geheel efficienter doordat delen samen gevoegd kunnen worden.

------


Ik ben erg benieuwd naar jullie meningen/ervaring etc.

[gorgi_19]

De voordelen (volgens mij) door overal functies te gebruiken:
Er zit een extra "laag" tussen de gegevens zit (dus betere beveiling van de gegevens) en de uiteindelijke invoeractie. De code kan allemaal op 1 pagina worden gezet (include).
Ik hoef alleen de function in de andere pagina aan te roepen om gegevens in te voeren.
Fouten zijn makkelijk op te sporen.
Ik hoef dezelfde code niet vaker te typen of ietsjes aan te passen.

Deze methode heeft wel een nadeel. Stel je hebt 100 functies, die je iedere keer include. Als je maar 1 functie gebruikt, moet je wel steeds alle 100 functies inladen. Zorgt ook voor enorme overhead.
Dit is een afweging tussen overhead en gebruik van functies.

Zoveel mogelijk dezelfde pagina's te gebruiken. Als er nieuwe menu's toegevoegd worden aan het bezoekers deel van de pagina of beheers gedeelte van de pagina, zijn deze schermen (kwa uiterlijk) bijna identiek (de beheerspagina heeft een paar extra opties). Is het in dit geval dan niet handig om 1 pagina te maken en bijvoorbeeld afhankelijk van de gebruiker id de extra velden weer te geven en andere functies te gebruiken etc?

De methode die je beschrijft komen heel erg overeen met de werking van een cms. Een pagina, b.v. default.aspx, wat eigenlijk een template is. Alleen de content c.q. paginaspecifieke tekst veranderd.
De methode is volgens mij ideaal in gebruik met bijvoorbeeld een database; zelfs de menu kan dan automatisch gegenereerd worden (of dit wenselijk is in verband met overhead is een tweede..)

Mijn persoonlijke ervaring zegt mij dat dit een programmeer omgeving zoals VB of delphi een hele goede manier zou zijn, omdat het hier geen scripting taal betreft en daardoor voordelen bied kwa snelheid en uitvoer etc (hier ga ik verder ff niet dieper op in).
Maar is dit een gangbare manier van werken op het internet.
Is deze manier bijvoorbeeld wel snel genoeg? of zou het gewoon sneller zijn 2 pagina's (of meerdere) te maken die bijna hetzelfde zijn?

Inderdaad is het zo dat serverside VBScript en JScript als nadeel hebben dat deze niet compiled zijn en daarom voor vertraging zorgen. Delphi en VB, COM-objecten in het algemeen, worden volgens mij minder op de server gebruikt, mede vanwege de complexiteit. Zo een object moet geregistreerd worden en IIS moet herstart worden. De meeste hostingbedrijven ondersteunen het gebruik van eigen gemaakte COM-objecten ook niet (met uitzondering van de duurdere pakketten)

Om het programmeergedeelte efficient te houden, kan je kiezen voor een 3-tier structuur; in ASP 3.0 is dit mogelijk (zij het wat lastiger); in .NET heel veel makkelijker.

Maar is een goede pagina? Tsja, een pagina die goed werkt en waar fouten makkelijk in op te sporen zijn en wijzigingen makkelijk en snel in aangebracht kunnen worden.

[blijhoofd_bennie]

Op zondag 09 juni 2002 13:26 schreef gorgi_19 het volgende:

[..]

Deze methode heeft wel een nadeel. Stel je hebt 100 functies, die je iedere keer include. Als je maar 1 functie gebruikt, moet je wel steeds alle 100 functies inladen. Zorgt ook voor enorme overhead.
Dit is een afweging tussen overhead en gebruik van functies.
[..]

De methode die je beschrijft komen heel erg overeen met de werking van een cms. Een pagina, b.v. default.aspx, wat eigenlijk een template is. Alleen de content c.q. paginaspecifieke tekst veranderd.
De methode is volgens mij ideaal in gebruik met bijvoorbeeld een database; zelfs de menu kan dan automatisch gegenereerd worden (of dit wenselijk is in verband met overhead is een tweede..)
[..]

Inderdaad is het zo dat serverside VBScript en JScript als nadeel hebben dat deze niet compiled zijn en daarom voor vertraging zorgen. Delphi en VB, COM-objecten in het algemeen, worden volgens mij minder op de server gebruikt, mede vanwege de complexiteit. Zo een object moet geregistreerd worden en IIS moet herstart worden. De meeste hostingbedrijven ondersteunen het gebruik van eigen gemaakte COM-objecten ook niet (met uitzondering van de duurdere pakketten)

Om het programmeergedeelte efficient te houden, kan je kiezen voor een 3-tier structuur; in ASP 3.0 is dit mogelijk (zij het wat lastiger); in .NET heel veel makkelijker.

Maar is een goede pagina? Tsja, een pagina die goed werkt en waar fouten makkelijk in op te sporen zijn en wijzigingen makkelijk en snel in aangebracht kunnen worden.

Kun je me misschien uitleggen hoe dat zit met die 3-tier structuur, want dat ontgaat me ff (misschien een page?)

Dat met die 100 functies klopt waar ik er 1 van gebruik klopt. Maar dit zou ik natuurlijk gedeeltelijk kunnen opvangen door de functie pagina's in te delen in verschillende onderdeel, dus check functies, invoer functies, delete functies. Dan heb ik natuurlijk wel veel pagina's maar de overhead wordt dan redelijk goed gecompenseerd. En dan kan de pagina geinclude worden die nodig is voor de actie die de gebruiker op dat moment wens

[gorgi_19]

Op zondag 09 juni 2002 13:52 schreef blijhoofd_bennie het volgende:

[..]

Kun je me misschien uitleggen hoe dat zit met die 3-tier structuur, want dat ontgaat me ff (misschien een page?)

Dat met die 100 functies klopt waar ik er 1 van gebruik klopt. Maar dit zou ik natuurlijk gedeeltelijk kunnen opvangen door de functie pagina's in te delen in verschillende onderdeel, dus check functies, invoer functies, delete functies. Dan heb ik natuurlijk wel veel pagina's maar de overhead wordt dan redelijk goed gecompenseerd. En dan kan de pagina geinclude worden die nodig is voor de actie die de gebruiker op dat moment wens

3-tier structuur: scheiding van presentatielaag, business-logic en databaselaag. Oftewel een duidelijke scheiding tussen deze drie onderdelen; een vormgever ziet geen code door zijn pagina heen, programmeur hoeft zich niet met lay-out bezig te houden, etc.

Op o.a. Microsoft is vast wel genoeg erover te vinden, anders via Google

[Crazy D]

Op zondag 09 juni 2002 13:52 schreef blijhoofd_bennie het volgende:
Dat met die 100 functies klopt waar ik er 1 van gebruik klopt. Maar dit zou ik natuurlijk gedeeltelijk kunnen opvangen door de functie pagina's in te delen in verschillende onderdeel, dus check functies, invoer functies, delete functies. Dan heb ik natuurlijk wel veel pagina's maar de overhead wordt dan redelijk goed gecompenseerd. En dan kan de pagina geinclude worden die nodig is voor de actie die de gebruiker op dat moment wens

Ja alleen jammer dat in asp de files eerst geinclude worden, en dan pas wordt de hele pagina geparsed. De includes die je in een if zet, worden ook eerst geinclude.

[blijhoofd_bennie]

Op zondag 09 juni 2002 16:47 schreef Crazy_D het volgende:

[..]

Ja alleen jammer dat in asp de files eerst geinclude worden, en dan pas wordt de hele pagina geparsed. De includes die je in een if zet, worden ook eerst geinclude.

Dat is niet zo mooi, heb in een boek gelezen dat ASP 3.0 hier wel betere oplossingen voorhad. Maar als ik jou reactie lees is dat dus niet zo, is wel vet minder dan.

[gorgi_19]

Waar je op doelt is waarschijnlijk Server.Transfer en Server.Execute

[blijhoofd_bennie]

Op zondag 09 juni 2002 17:50 schreef gorgi_19 het volgende:
Waar je op doelt is waarschijnlijk Server.Transfer en Server.Execute

Raakt wel een beetje off-topic, maar zal het nog eens opzoeken.

Vraagje:
Wat is bij ASP het gangbare aantal functies om op een include pagina te hebben m.b.t overhead en performance?

En hoe staan jullie tegen over het idee om de functie pagina's op te splitsen?
Dus een functie pagina voor checks, insert/update/delete acties (verdeling kan natuurlijk altijd iets beter, maar is een voorbeeld). En dan alleen de pagina te includen voor de actie die op dat moment gewenst is. Beperkt lijkt me redelijk overhead beperkend (afgezien van het feit dat je altijd "nutloze" functies overhoud die je nou net niet nodig hebt voor de page.

[gorgi_19]

Tsja, hoe kleiner het includebestand, hoe minder overhead en deze scheiding die houdt alles nog redelijk in de hand.
Lijkt me in ieder geval beter dan veel-te-veel functie includen, die je toch niet gebruikt.

Waar de grens ligt van aantal? Tsja, dat kan je het beste gaan stress-testen om hier achter komen; wat je nog een acceptabele performance vindt.

Maar nu ik je post zo doorlees, is ASP.Net geen optie om te gebruiken i.p.v. ASP 3.0?

[gotcha]

ik zou al je functies in een COM+ componentje stoppen (maken met VB6 ofzo). ben je gelijk af van je include-files, plus de performance van het componentje is een stuk beter dan die van ASP.
en idd... als de mogelijkheid er is dan zou ASP.NET de betere keuze zijn, echter de overstap van ASP naar ASP.NET is niet zo makkelijk als over het algemeen beweerd wordt. wil je een beetje goed gebruik maken van wat .NET te bieden heeft dan zul je d'r best wat tijd voor uit moeten trekken

[blijhoofd_bennie]

reply gotcha en gorgi_19

Ik ben dus ervaring met de ASP voor visualstudio.net (dit is toch 3.0?)
Wat me persoonlijk ook (nog) niet weet is? is ASP.net nou een nieuwe taal of gewoon een nieuwe ontwikkelomgeving? Hier moet ik nog eens ff naar zoeken op internet. (goede pagina's of informatie zijn alijtd welkom natuurlijk )

[gorgi_19]

Probeer eens: www.asp.net?

Visual Studio 6 = VB6 + ASP 3.0 pages
Visual Studio.Net = VB.Net + ASP.Net pages