[ASP.NET/C#] Grote webpages

[Verwijderd]

Misschien een rare vraag, maar ik stel hem toch...

Ik ben voor mijn stage bezig met een C#/ASP.NET web-toepassing. Ik moet een soort catalogus bouwen. Nu zit ik in mijn gedachten met een 3tal pagina's in mn hoofd.

Dat is: Publication / Maintenance / Add

Deze paginas gaan vrijveel code bevatten... In publication komt bijvoorbeeld alle soorten publicatie die mogelijk is binne mijn site. Nu ben ik bekend met de techniek om dat overzichtelijk te doen (mijn homepages bestaan ook meestal uit een file met alle code erin (in ASP)) via if en switches te gebruiken.

Nu heb ik ergens gezien dat C# code gecompileerd wordt door je webserver... Dat was vroeger met ASP volgens mij niet het geval... Nu vraag ik me dus af of het wel zo verstandig is om alles in 1 file te zetten. Want als die hele lap code dan gecompileerd moet worden kost het me teveel processor tijd denk ik......

Maar eigenlijk lijkt in 1 file beter, omdat je gezamelijke functies kunt gebruiken en bepaalde zaken van de ene request kunt recyclen in de andere (zoals layout ed)....

Nu is dus eigenlijk mijn vraag aaan jullie: bundel de acties in 3 files of schrijf voor alle acties aparte pages????

[Janoz]

Ikzelf gebruik het model view controler model. Ik maak gebruik van Struts . Alles in 1 pagina zou ik niet 'een techniek' willen noemen. Zowiezo is layout iets wat volkomen los staat van de rest (tenminste, in het ideale geval)

[Postman]

Als het echt gecompileerd wordt door de server loop je met 1 groot bestand misschien tegen problemen aan idd.

Maar is C# niet OO? Als dat zo is zou je namelijk gebruik moeten maken van aparte classes enzo, en dus losse bestanden voor elke actie.

[Verwijderd]

FlamerX schreef op 23 October 2003 @ 15:10:
Als het echt gecompileerd wordt door de server loop je met 1 groot bestand misschien tegen problemen aan idd.

Maar is C# niet OO? Als dat zo is zou je namelijk gebruik moeten maken van aparte classes enzo, en dus losse bestanden voor elke actie.

In principe is het OO, maaaaar als je een web app gaat bouwen is OO niet echt nuttig. De enige techniek die ik moet gaan gebruiken is het scheiden in een Application en Presentation layer. Dus de applayer moet de data uit een DB rukken en de Presentation leuk op t scherm zetten. Tussen die 2 methods wordt met XML gegooid.

Het heeft in mijn ogen weinig nut om voor presentatie en/of schrijven in een DB met objecten te gaan werken...

[whoami]

Je page wordt maar 1x gecompiled, en of je nu in je project 1 of duizend bestanden hebt, die worden allemaal tot 1 dll gecompiled.

Ik bedoel natuurlijk dat je C# code slechts 1x naar IL wordt gecompiled. De eerste bezoeker die je site bezoekt zal dan wel wat vertraging ondervinden omdat die IL dan naar native code moet gecompiled worden.
Echter, dat is redelijk verwaarloosbaar.

Je hebt trouwens een tooltje in .NET (ngen dacht ik) die je IL direct naar native code compiled.

[ Voor 118% gewijzigd door whoami op 23-10-2003 15:24 ]

[Postman]

whoami schreef op 23 October 2003 @ 15:15:
Je page wordt maar 1x gecompiled, en of je nu in je project 1 of duizend bestanden hebt, die worden allemaal tot 1 dll gecompiled.

Dan zou ik voor de oplossing "alles-in-1-bestand" gaan.

[Blorgg]

.net doet een klein beetje als jsp. Je source wordt een keer gecompiled naar een Microsoft Intermediate Language welke daarna 'at run time' naar zijn uiteindelijke staat(native language) wordt gecompiled en uitgevoerd. Je hoeft daarom niet echt bang te zijn dat teveel source code in een bestand de boel erg gaat vertragen. Of het overzichtelijk is wat het coden aangaat is een andere vraag.

[whoami]

FlamerX schreef op 23 October 2003 @ 15:20:
[...]

Dan zou ik voor de oplossing "alles-in-1-bestand" gaan.

Nouja, ik niet.
Onderhoudbaarheid, beheersbaarheid, .... Allemaal even belangrijk.
Wat ik zeker niet zou doen is om je HTML en code in 1 bestand gaan zetten. Maak gebruik van code-behind.

[Verwijderd]

whoami schreef op 23 October 2003 @ 15:25:

[...]


Nouja, ik niet.
Onderhoudbaarheid, beheersbaarheid, .... Allemaal even belangrijk.
Wat ik zeker niet zou doen is om je HTML en code in 1 bestand gaan zetten. Maak gebruik van code-behind.

dus ik zou het aantal moeten verdubbelene.

Dus voor publication bv: pubPresentation.aspx en pubApplication.aspx

waarbij in de pubApplication.aspx de data wordt opgevraagd uit de db en gegenereerd als XML. daarna in presentation via een functie mn interface genereren....

dus als ik bv vraag pubPresentation.aspx?action=show&id=2 datie aan mijn application vraagt om daar een XML te maken en die dan in de presentation presenteren....


Begrijp ik t goed? Dat is idd wel handiger, want dan kan je de GUI van je applicatie halen en een nieuwe presentation gebruiken en via andere pages ook je presentation aanvragen....

en dat van het compilen komt moooi uit! Daar zat ik namelijk wel een beetje mee, moet nl op een vrij drukke server komen, en dan wil ik niet dat mijn appje alles op houd!

[whoami]

Ik zou zeggen:
start VS.NET eens op, en maak eens een simpele ASP.NET applicatie. In VS.NET werkt je zowiezo met code-behinds. Je hebt een aspx file, en een cs file. De aspx file bevat je controls en je HTML, terwijl je cs file de code bevat.

[Verwijderd]

whoami schreef op 23 oktober 2003 @ 15:35:
Ik zou zeggen:
start VS.NET eens op, en maak eens een simpele ASP.NET applicatie. In VS.NET werkt je zowiezo met code-behinds. Je hebt een aspx file, en een cs file. De aspx file bevat je controls en je HTML, terwijl je cs file de code bevat.

ehm ik heb zo 1..2..3.. geen VS.net bij de hand

En thuis draai ik Borland C# Builder, omdat ik VS een beetje prijzig vind om mee te expirimenteren....

[sander_g]

Je hoeft niet Visual Studio .NET aan te (laten) schaffen. Neem Visual C# of Visual Basic.NET. Dat kost ongeveer 120 euro. Je kunt dan weliswaar alleen ontwikkelen in die betreffende taal. Maar verder bevat het vrijwel alle functionaliteit van de volledige Visual Studio.NET.

Als je echt geen budget hebt, kan je ook nog ASP.NET Web Matrix proberen.

[whoami]

In C# Builder werk je ook met code-behind.
WebMatrix moet je niet proberen; voor zover ik weet wordt je daar niet verplicht om met code-behind te werken (alhoewel je het wel kan hoor), maar WebMatrix is totaal niet te vergelijken met VS.NET of C#Builder

[ Voor 54% gewijzigd door whoami op 23-10-2003 15:58 ]

[Verwijderd]

Verwijderd schreef op 23 October 2003 @ 15:12:
[...]

In principe is het OO, maaaaar als je een web app gaat bouwen is OO niet echt nuttig.

Daar ben ik het niet mee eens. Als je een grote site bouwt is OO een uitkomst. Ik bouw zelf portals, en dan gebruik ik heel wat objecten, waaronder inderdaad een databobject die connectie maakt met de database en bijhoudt hoeveel hits je hebt. Daar hangt een query-object aan, zodat deze makkelijk te manipuleren is. Afgeleiden daarvan zijn het brief en detail object voor lijst/detail records. Verder nog een UserInterface object die xsl's inlaadt en params doorgeeft etc...

Kijk ook eens hier naar als je geen VS.net wil kopen: http://www.icsharpcode.net/OpenSource/SD/
Gratis open source visual studio achtig.

[whoami]

Waarom zou OO bij een webpage niet nuttig zijn?

Bij een webapplicatie is het van belang dat je applicatie schaalbaar is, en meerdere users aankan.
Om dit te verwezenlijken kan je je software in lagen gaan schrijven: data access laag, business logic laag en een presentatie-laag.
In deze lagen ga je zeker gebruik moeten maken van OO technieken. OO zorgt er nl. voor dat je makkelijker verstaanbare code schrijft die beter aanpasbaar en onderhoudbaar is.
Waarom zou dus volgens jou OO geen goed idee zijn bij webapplicaties?

[Scharnout]

En hoe gebruik je die layers dan precies. Ik ben net begonnen met een grote website, maar de business logic laag gebruik alleen maar om de data door te geven en is dus onnodig. Ik zou eigenlijk mijn code-behind meer als business logic willen zien, dan een aparte laag.

En hoe ga je bijvoorbeeld om met je site als je er op 90% van het design achter komt dat je eigenlijk nog meer functionaliteit wilt hebben en dan zelfs je database moet aanpassen. Of erger nog ... je site is al af en in productie ...

[whoami]

Je moet natuurlijk geen complexiteit toevoegen als die niet nodig is. Als je geen business logica hebt, is het dan ook onzinnig om een BL laag toe te voegen.
Een goed design is belangrijk, maar er mag ook niet in overdreven worden. Het design is het project niet. Als je geen BL of geen complexe BL hebt, dan kan je dat imo eventueel in de presentatie-laag opnemen.
Echter, het is moeilijk om een echte grens te trekken, business logic wordt soms ook in de DB toegepast dmv stored procedures.

[mOrPhie]

Scharnout schreef op 24 October 2003 @ 20:34:

En hoe ga je bijvoorbeeld om met je site als je er op 90% van het design achter komt dat je eigenlijk nog meer functionaliteit wilt hebben en dan zelfs je database moet aanpassen. Of erger nog ... je site is al af en in productie ...

Mjah, buiten dit hele topic is dit natuurlijk een enorm algemene vraagstelling, waar heel veel bedrijven al heel wat tijd in hebben gestoken. Er zijn zoveel verschillende oplossingen voor, dat jij en ik dit niet even in dit topic verzinnen.

Zoals whoami al terecht opmerkt moet je het niet moeilijker maken dan het is, maar ik ben met je eens, als de site aan verandering in de code onderhevig is, dan zul je het wel enigzins moeten structureren. Maar dat is ook meteen het gevaar. Als iemand denkt aan "structuur" dan zijn ze al bijna bezig met en 3-tier ontwerp, terwijl in een simpel ontwerp best een goeie structuur kan zitten. Neem php. Ook als je geen classes gebruikt kun je best de functies die je maakt scheiden in data en business. Het heeft verder weinig met echte laag-scheiding te maken, maar er is wel een structuur.

whoami schreef op 25 October 2003 @ 10:29:
Echter, het is moeilijk om een echte grens te trekken, business logic wordt soms ook in de DB toegepast dmv stored procedures.

Jups, en user defined functions. En triggers. Oh well, wat mssql al niet kan doen om het overzicht tussen business en data te verliezen. Het zijn allemaal erg mooie features die mssql kent, maar ook erg gevaarlijk als je veranderingen aan je site hebt zoals Scharnout stelt.