Werkwijze van programmeur

[Dayhmian]

Goedemiddag leden

vraag 1:
Ik heb een vraag betreffende de werkwijze van de programmeur als het gaat om bestanden in zijn programma.
Als we op de computer een bestand map van een bepaald programma openen dan zien we dat de bestanden georganiseerd zijn. Dus niet alle files bevinden zich in 1 map maar het is verdeeld over meerdere.

Is er voor deze manier van werkwijze een benaming of regels?
Of is het aan de programmeur om de indeling te maken van zijn folders in een programma


vraag 2:
Ik ben aan het oefenen met xml files en ben een inlogform aan het maken, de xml file ga ik encrypteren.
Is het gebruikelijk om hiervoor xml te gebruiken of is een inlogform standaard een database?


Bij voorbaad dank,
Met vriendelijke groet,

[TERW_DAN]

Geen idee of die indeling een naam heeft, maar het zal gebaseerd zijn op best practices. Het is logisch dat je je binary files in een bin-directory zet bijvoorbeeld.
Voor je programma maakt het niet zoveel uit, als je die bestanden maar hebt.

[edeboeck]

Om op vraag 2 in te gaan: geen van beiden. Allicht heb je het echter over de plaats waar de inloggegevens opgeslagen worden: daar heb je de vrije keuze in, al is het wel in de praktijk noodzakelijk om wachtwoorden versleuteld op te slaan. Om te oefenen kan je zoiets zelf implementeren, maar maak voor de praktijk zeker gebruik van bestaande, bewezen veilige, oplossingen.

[Dayhmian]

@TERW_DAN

Dus een beetje een logische eigen indeling maken zal opzicht dan voldoende moeten zijn.

dank voor de snelle reactie.
fijne feestdagen.

[Dayhmian]

@edeboeck

Klopt daar heb ik het inderdaad over.
Ik zal er eens in duiken op de bestaande veilige manieren, hetgeen wat ik nu doe is puur om te oefenen met xml. Als ik een beetje rondkijk en bijvoorbeeld google op "C# login form wijzen de meeste naar het gebruik van een database".

dank voor de reactie.
en fijne feestdagen.

[jeroen3]

1. Het concept van een bestandssysteem is zo basis dat ik niet eens weet of er een speciale term voor is.
Soms gebruikt men wel eens "directory traversing".

2. XML is een vrij dure implementatie voor opslag, omdat het best ingewikkeld werkt. Veel gebruikelijker is SQlite. Maar dat laat zich wat minder goed verzenden, waar json of protobuf weer erg goed in zijn.
Maar ik denk dat je opslag zoekt voor lokale applicatie, en daar is SQlite best handig. In hoeverre de encryptie hiervan toerijkend is weet ik niet.

[Dayhmian]

@jeroen3

Dank Jeroen, zal er eens induiken.

groet,
fijne feestdagen

[AW_Bos]

Veel succes....
Enne.....Eén keer fijne feestdagen is ook wel prima hoor

[Dayhmian]

@AW_Bos

Haha, ja zag het.

[Mugwump]

Dayhmian schreef op dinsdag 24 december 2019 @ 12:23:
Goedemiddag leden

vraag 1:
Ik heb een vraag betreffende de werkwijze van de programmeur als het gaat om bestanden in zijn programma.
Als we op de computer een bestand map van een bepaald programma openen dan zien we dat de bestanden georganiseerd zijn. Dus niet alle files bevinden zich in 1 map maar het is verdeeld over meerdere.

Is er voor deze manier van werkwijze een benaming of regels?
Of is het aan de programmeur om de indeling te maken van zijn folders in een programma

In algemene zin is dat doorgaans vooral een logische groepering van dingen die bij elkaar horen.
Het is wel zo dat bepaalde programmeertalen en / of bepaalde build tools conventies hebben wat betreft directorystructuren.

Als je bijvoorbeeld code in Java schrijft, dan heb je te maken met de zogenaamde Java package structuur. Die package structuur schrijft ook weer voor hoe je bestanden in directories moeten worden geplaatst. Als jij bijvoorbeeld de package 'net.tweakers.gathering.demo' zou gebruiken, dan moeten je source files in de directory /net/tweakers/gathering/demo staan. Eventuele groeperingen die je daar nog weer verder in onder brengt in subpackages komen ook weer in subdirectories te staan.

Gebruik je een build tool als Maven, dan heb je ook nog weer een standaardconventie voor de directorystructuur (al kun je daar wel van afwijken als je de settings expliciet aanpast).

Kijk je naar hoe bestanden met code precies gegroepeerd wordt, dan heb je in hoofdlijnen eigenlijk twee opties, simpelgezegd een technische en een functionele groepering. Heb je bijvoorbeeld een simpele webshop dan hanteer je vaak iets van een 'model-view-controller' structuur. De technische groepering is dan bijvoorbeeld je models bij je models, de views bij de views, de controllers bij de controllers, services bij services en ga zo maar door. Bij een functionele groepering zet je de code bij elkaar die ook functioneel bij elkaar hoort. Bijvoorbeeld alle code voor het winkelwagentje bij elkaar, de code voor het contactformulier bij elkaar, de code voor de productpagina's bij elkaar en ga zo maar door. Er bestaat daarin niet per se een goede of een foute manier, maar veel mensen hebben wel uitgesproken voorkeuren.

[downtime]

Dayhmian schreef op dinsdag 24 december 2019 @ 12:23:

vraag 2:
Ik ben aan het oefenen met xml files en ben een inlogform aan het maken, de xml file ga ik encrypteren.
Is het gebruikelijk om hiervoor xml te gebruiken of is een inlogform standaard een database?

Een inlogform is standaard geen van beide. Files (zoals XML) en databases zijn manieren om data op te slaan. Een inlogform is (een gedeelte van) een applicatie die login credentials verwerkt. Die login credentials kunnen op allerlei verschillende manieren door die applicatie opgeslagen worden. Files of database zijn allebei bruikbaar.

XML is alleen niet erg gebruikelijk voor opslag van credentials. Het is er ook niet voor bedoeld. XML is vooral bedoeld als tussenformaat om gegevens tussen applicaties uit te wisselen of voor opslag van kleinere hoeveelheden statische data (bv. configuratiebestanden).
Het grote voordeel van XML is namelijk dat het voor mensen (relatief) leesbaar is, platformonafhankelijk, goed gestandaardiseerd (ondermeer d.m.v. schema's) en erg flexibel. Het heeft ook nadelen. Zo is het tamelijk inefficient wat het minder geschikt maakt voor toepassingen met veel data die ook vaak wijzigt. Maar voor een kleine website waar je geen honderdduizenden accounts hebt zal het prima werken. Naarmate de website groeit kies je vaak toch voor een database omdat alle problemen waar je dan tegenaan loopt in een behoorlijke database al opgelost zijn.