En simpel tekstfil

Det er meget simpelt at skrive til en fil i .NET (som også gælder ASP.NET):

 Dim path As String = Server.MapPath("~")
             Dim filename As String = "myFile.txt"
             Dim completePath As String = System.IO.Path.Combine(path, filename)
             Using sw As System.IO.StreamWriter = New System.IO.StreamWriter(completePath)
                 sw.WriteLine("hello world")
                 sw.Flush() 'Dette skriver det endeligt til filen
             End Using

Hvis du ønsker det i C# er syntaksen kun en lille smule anderledes:

 string path = Server.MapPath("~")
 string filename = "myFile.txt"
 string completePath = System.IO.Path.Combine(path, filename)
 Using (sw As System.IO.StreamWriter = New System.IO.StreamWriter(completePath))
 {
       sw.WriteLine("hello world")
       sw.Flush()
 }

Så skal du blot finde din egen logik for hvordan du vil skrive i filer, eller hvordan du vil holde styr på det.
Kan godt blive lidt noget besværligt rod som ikke er for kønt, men det er en mulighed for at få det til at fungere.
Søgninger bliver lidt mere specielle, og jo større din brugergruppe bliver jo mere ineffektiv vil denne løsning sandsynligvis blive.

Hvilken uddannelse er du igang med, at tage siger du?

Skal det være ASP.NET, ellers ligger der tonsvis af guides til PHP - hvordan du skriver til en TXT fil.

Overvej at udfordre jer selv og lær samtidig noget der kan bruges i den virkelige verden :-)

Hvis i vil vælge filer, så prøv med XML. Der er en hurtig guide her:

http://paulsiu.wordpress.com/2007/04/04/creating-a-xml-document-from-scratch-without-using-a-file-in-c/

NEEJ! Drop XML, det er alt for verbost. Hvis du endelig vil skrive til en tekst fil, så benyt noget simplere, som en INI fil, YAML, eller JSON.

Som allerede nævnt så kan det blive rigtigt rigtigt besværligt at forstå, og holde styr på - og oveni vil det være en dårligt performende løsning som kun vil blive dårligere jo mere data der kommer. Kompleksiteten i den logik der skal ligge bag vil næsten altid være meget høj, og tvivler på det er noget jeres lærere vil synes er en god løsning - eller censor for den sags skyld.
Det vil helt klart være bedre at "spilde" sin tid på at lære at gøre det rigtigt i en database og det er faktisk heller ikke så svært endda.
Her er der mange gode muligheder med rollbacks, indexes etc. som kan hjælpe dig med at få forbedret din kode og kompleksitet.
Det vil være meget meget svært at forsvare valget af en tekstfil fremfor en database, og vil næsten aldrig give point vil jeg mene.

Men hvis det endeligt skal være, ville jeg ligesom Jakob også vælge JSON netop fordi det er kort, effektivt og simpelt. Der er en meget nem syntaks, du kan have en lagdeling som på samme måde i XML, men langt mere effektivt og nemmere læseligt og forståeligt.
Du vil nemt kunne læse og forstå det, datatransporten vil være meget mere effektiv fremfor XML, og dernæst vil jeg også tro at en censor ville mene at valget med effektiv datakommunikation i form af JSON vil være et bedre valg fremfor XML.

NEEJ! Drop XML, det er alt for verbost. Hvis du endelig vil skrive til en tekst fil, så benyt noget simplere, som en INI fil, YAML, eller JSON.

Slet ikke enig. Jeg bruger XML i stor stil og det betyder meget i vores situation, at kunne være strikse i dokumentopbygningen, m.m.

Men dog enig i, at JSON er godt. Men det ene udelukker ikke det andet ;-)

Det eneste XML kan, som JSON ikke kan er rækkefølge i lister - men det burde man alligevel i de fleste tilfælde heller ikke bekymre sig om i datatransporten.

XML fylder godt og vel det dobbelte af en JSON fil:

<nodeName>value</nodeName>

fremfor

{ nodeName: 'value' }

XML er frygteligt at navigere rundt i (når man benytter DOM i hvert fald, XPath retter op på noget af det)

XML "kræver" en header (<?xml ...?> og diverse schemas), som giver overflødigt overhead på dataoverførslen.

Alt i alt kan jeg ikke se mange positive sider ved XML, og benytter det kun selv når jeg koder op imod API's hvor der ikke er andre valg.

Men jeg koder heller ikke store business solutions osv. så jeg overser sikkert nogle usecases i det store business liv. Og nej - Det ene udelukker vel ikke det andet