Filstruktur

Tags:    .net

Hej udviklere,

Jeg er i øjeblikket, sammen med en kammerat, i gang med et større projekt (mit første større projekt i asp.net) og jeg kom i den forbindelse til at tænke på hvad der vil være det mest hensigtsmæssige, overskuelige og "økonomiske" (når det kommer til antallet af filer) når det gælder fil- og mappestruktur?

Siden består af selve hjemmesiden og så et CMS system bagved. Siden bliver kodet på en måde så man nemt kan installere moduler på siden.

Er det smartest at have designet i en .master fil og så have en masse filer de enkelte sider linker til, eller er det smartest at have designet i default.aspx og så enten bruge server.execute() eller include til at hente de filer der nu skal bruges udefra, eller hvordan?

Og hvad med selve c# delen - skal jeg lave en .cs fil til hver enkel aspx fil eller skal jeg f.eks. lave én stor funktionsfil med de funktioner der går igen, og så lave nogle mindre .cs filer til de individuelle filer eller?

Som I kan se er det en del spørgsmål, og jeg er lidt på bar bund her.

På forhånd mange tak for hjælpen.



6 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 4 karma
Sorter efter stemmer Sorter efter dato
Masterpages!!



hehe det var et endnu større spørgsmål :-)

En klasse/class er en logisk sammenhæng af "ting". Dvs det er typisk hvor de ting den består af har nogle ting til fælles. Et eksempel kan være en bil klasse, hvor alle "ingene" har det til fælles at de hører til en bil, fx. hjul, farve, nummerplade, mærke, benzinforbrug osv.

I programmering er det typisk det vil vil lave, en model af virkeligheden, oversat til computersprog, og så "give" den tilbage til brugeren i form af et stykke software, her hjælper klasser os til at forme vores software efter hvordan brugerens virkelighed hænger sammen.

Når man snakker klasser i en applikation taler man ofte om forretningslogik (Business Logic Layer, BLL) - de er den samling af klasser der bygger hele det område dit software skal dække.

Når du skal skrive en ASP.NET applikation der eksempelvis skal lave det muligt at booke billetter i en biograf, skal du have en biograf-klasse, en sal-klasse, en film-klasse og en sæde-klasse. Alle disse klasser skal arbejde sammen om at udføre alt det "forretningslogik" som din biografbooking software skal udføre.

Dette var meget kort fortalt, håber det hjalp lidt. Det er svært at forklare, der er noget her der måske kan hjælpe, det er førsteårs undervisningsmateriale fra Aalborg Universitet til udvikling af C# applikationer. Det er supergodt og detaljeret og fantastisk at han har lagt det på nettet: http://www.cs.aau.dk/~normark/oop-csharp/html/notes/theme-index.html



Puuha stort spørgsmål...

Personligt er jeg den type der ikke ser et problem med antallet af filer, så længe det er organiseret overskueligt og det giver mening. Jeg har flere projekter med over 1000 filer i.

Jeg ville lave en mappe til hvert delsystem, fx. moduler, forretningslogik, services osv. og så i de mapper have de klasser der giver mening i den kontekst.

Er det smartest at have designet i en .master fil og så have en masse filer de enkelte sider linker til, eller er det smartest at have designet i default.aspx og så enten bruge server.execute() eller include til at hente de filer der nu skal bruges udefra, eller hvordan?


Lav en side (abc.aspx samt abc.aspx.cs) pr. "side i dit system", lad være med at lave det hele i een stor pærevælling, husk på at du også skal kunne finde ud af at vedligeholde det efterfølgende.

Lav dit design i din .master fil, og så lav sider for hver af de sider der skal linkes til, der så IKKE indeholder forretningslogik, men kun reference til dine forretningslogik klasser som så står for alt der praktiske.


Og hvad med selve c# delen - skal jeg lave en .cs fil til hver enkel aspx fil eller skal jeg f.eks. lave én stor funktionsfil med de funktioner der går igen, og så lave nogle mindre .cs filer til de individuelle filer eller?


Jeg tror du skal tænke mere objektorienteret, du fokuserer på "funktionsfiler" og det mener jeg er forkert! Du skal derimod lave klasser der indkapsler din logik og så er det dem du beder om at udføre en opgave fx. en Kunde klasse, kan oprette, slette, opdatere og læse en kunde, den kalder så videre ned til noget der kan snakke med databasen, så du ALDRIG i din side skal bekymre dig om det. (jeg flytter altid dette ud i et selvstændigt projekt, så det kan genbruges til fx. webservices).

Det er lidt svært at forklare hvis ikke du er helt med på det, men det handler om opdeling, og gruppering af ansvar og så må du spørge til enkeltelementer af det jeg har skrevet hvis du vil have dybere svar :-) det er meget omfattende, og dette er min holdning til hvordan tingene skal laves.




Puuha stort spørgsmål...

Personligt er jeg den type der ikke ser et problem med antallet af filer, så længe det er organiseret overskueligt og det giver mening. Jeg har flere projekter med over 1000 filer i.

Jeg ville lave en mappe til hvert delsystem, fx. moduler, forretningslogik, services osv. og så i de mapper have de klasser der giver mening i den kontekst.

Er det smartest at have designet i en .master fil og så have en masse filer de enkelte sider linker til, eller er det smartest at have designet i default.aspx og så enten bruge server.execute() eller include til at hente de filer der nu skal bruges udefra, eller hvordan?


Lav en side (abc.aspx samt abc.aspx.cs) pr. "side i dit system", lad være med at lave det hele i een stor pærevælling, husk på at du også skal kunne finde ud af at vedligeholde det efterfølgende.

Lav dit design i din .master fil, og så lav sider for hver af de sider der skal linkes til, der så IKKE indeholder forretningslogik, men kun reference til dine forretningslogik klasser som så står for alt der praktiske.


Og hvad med selve c# delen - skal jeg lave en .cs fil til hver enkel aspx fil eller skal jeg f.eks. lave én stor funktionsfil med de funktioner der går igen, og så lave nogle mindre .cs filer til de individuelle filer eller?


Jeg tror du skal tænke mere objektorienteret, du fokuserer på "funktionsfiler" og det mener jeg er forkert! Du skal derimod lave klasser der indkapsler din logik og så er det dem du beder om at udføre en opgave fx. en Kunde klasse, kan oprette, slette, opdatere og læse en kunde, den kalder så videre ned til noget der kan snakke med databasen, så du ALDRIG i din side skal bekymre dig om det. (jeg flytter altid dette ud i et selvstændigt projekt, så det kan genbruges til fx. webservices).

Det er lidt svært at forklare hvis ikke du er helt med på det, men det handler om opdeling, og gruppering af ansvar og så må du spørge til enkeltelementer af det jeg har skrevet hvis du vil have dybere svar :-) det er meget omfattende, og dette er min holdning til hvordan tingene skal laves.


Tusind tak - det hjalp lige med at få et par ting på plads; Det næste spørgsmål er så: Hvad er en class og hvordan bruger man den? Jeg har nu febrilsk i de sidste 2 timer forsøgt at forstå hvad præcist en class er og finde nogle eksempler på brug af classes, men det er kun halve svar og halve eksempler jeg kan få vist.

Ved ikke om du selv vil give en kort forklaring og eksempel, eller om du evt. har et link til noget godt læsestof?



Dit spørgsmål omkring hvad en class er, er lidt abstrakt, da man ikke lige i en oneliner kan forklare alt.
En klasse er en skitse af hvordan et objekt skal se ud. Når man snakker om klasser, så skal man også ind og snakke om objekt orienteret programmering, hvor man på bedst mulig vis prøver at modellere virkeligheden ved at indkapsle adfærd og definere klassernes afhængigheder.

Prøv at læs, http://www.devarticles.com/c/a/C-Sharp/Introduction-to-Objects-and-Classes-in-C-sharp/
Den objekt orienteret verden er en af mange måder en programmør kan beskrive og modellere det problem han prøver på at løse.



Martin og Brian:

Tusind tak begge to - jeg har nu endelig fattet hele pointen med classes og hvordan de kan bruges i mit arbejde.



t