Simulatorspel

Linq är riktigt fint när man väl börjat använda det!

Du skapar ett datacontext. Sen kan du köra följande för att få ut alla players. Det smidiga är att du kan skapa dina egna klasser direkt när du kör selecten!

MyDataContext db = new MyDataContext();
var players = from player in db select new Player(){Name=player.Name};

typ nåt sånt, bara pseudokod dock. Det fina är att du kan bygga upp ett query men inte köra det utan att anropa ToList vilket gör att du kan bygga upp ett query i flera steg och sen få fram ett optimerat query på det

Jag berömmer ditt engagemang KurreKula, det är inte vanligt att se här på forumet

och lycka till med projektet jokohanho

Alltid kul att kunna dela med sig av det man lärt sig genom åren Får själv ofta hjälp här!

Enligt mig ska du ha en tabell för ägare, en för placeringar och en för datorer. Sen i t.ex. datorertabellen har du en kolumn "Owner" som då är ett id som länkar ägaretabellen om du förstår vad jag menar...

Bör IP verkligen ligga där? Det kan ju bytas så ofta, risken är ju att din databas blir inaktuell fort

Jisses! Vore jag du skulle jag skippa databasen helt i detta stadie. Jag och en senior java konsult skrev ett större Java server system från scratch och vi började inte med databasen. Vi började med GUI och logiklagret. Vi använde XML filer för att lagra saker (men du kan lagra alla spelare i ram eller textfil) och rörde inte databasen alls i början. Jag tycker du ska börja med logiklagret och gui. Spara allt i RAM eller på textfiler. Sen på slutet, när allting är klart, så går du över till en riktig databas, men det görs sist. Vet du hur mycket jobb du har framför dig? Du kanske vill ändra klasserna och då ändras datamodellen (så du måste ändra alla tabeller i databasen totalt) och då har du gjort allt detta arbete med databaser i onödan.

Jag tycker du börjar i fel ände. Slutresultatet kanske skiljer sig totalt från databas tabellerna du har nu, du kanske får helt andra tabeller.

Fundera över datamodellen (alla databas tabeller, är de rätt?) och skapa Player klasser och sånt, och testa. Låtsas som att databasen redan finns tillgänglig och kör dummy kod och lagra allting i RAM eller textfiler.

Mina 5 cent.

Jojo, jag säger inte att du ska lägga ned projektet. Men jag säger att du ska börja med andra saker än databasen. Börja med att göra en simulering i ren text, börja med simuleringsmotorn. Sen lägger du på GUI, istället för text output. Sist lägger du till en databas.

Så, börja med simuleringarna men i text, typ

Tryck 1 för att göra en match, tryck 2 för att köpa en spelar, tryck 3 för....
1)
2)
3)
vad är ditt val? 1
Du vann matchen med 2-1
Vad är ditt val? 2
Vilken spelare vill du köpa?
A) Kalle Kula
B) Per Vers

etc. Så du kan spela ett spel. Sen, byter du ut texten mot ett GUI. Du bygger en knapp som man trycker på och då startas val 1). Sen när allt detta funkar och du kan spela lite spel, så börjar du med databasen.

Alltså, jag säger inte du ska lägga ned, utan att du ska börja i annan ände.

Problemet är databasens tabeller kräver jättemycket kodändringar om du ändrar nåt i tabellerna. Gör en liten ändring och det blir mycket kod som ska ändras. Och nu vet du inte hur du vill ha det, du vet inte vilka klasser som simuleringarna kommer att behöva. Om du gör databasen nu, så kanske det visar sig att du behöver helt andra tabller när du börjar med simuleringarna. Och då måste du ändra skitmycket kod.

Därför, kör simuleringarna så du vet vilken data du behöver lagra i databasen. Först då kan du göra databasen.

Det är som om att du försöker bygga ett hus, och huset existerar inte, men du börjar med möbleringen. Du planerar möbleringen och färgen och allting. Sen bygger du huset, och då kanske det visar sig att du kunde inte bygga 2våning, du måste bygga 1våning och då kan du inte ha köket högst upp, och då måste du ändra all möblering och design. Så du pausar bygget, börjar möblera på nytt. Sen fortsätter du bygger och då visar det sig att det går inte att bla, bla och då måste du möblera om allting igen. etc.

Det är bättre med att börja bygga huset, och vänta med möbleringen till sist, när huset är nästan färdigbyggt.

Alltså, börja med simuleringarna och vänta med databasen tills du kommit ganska långt med simuleringen. Helst ska du vänta med databasen tills du är helt färdig med simuleringsmotorn. Gör du på detta sätt så sparar du tid.

Vet ej hur mycket Linq du använt saddam men det är otroligt mycket enklare att ändra i databasen om man kör linq... Knappt nått jobb alls.

Det optimala är att man har allt klart för sig, in i minsta detalj, innan man börjar. Och då börjar från grunden och upp, och har full koll på exakt vad som krävs hela vägen till slutresultatet. Man har ORM-diagram, flödesscheman och klassdiagram klara och optimerar dessa under utvecklingen.

Men eftersom det inte är så i det här fallet, rekommenderar jag som saddam säger att du fokuserar på front-end och få klart grunden till alla mallar innan du börjar prata med databasen. Det är nämligen lättare för en nybörjare att jobba med visualiserande resultat och man inser då lättare i det senare skedet vilka tabeller och kolumner man faktiskt behöver.

Använd dummy-data som du låtsas få tillbaka från back-end, utan logik. Först när allt lirar byter du ut dessa förfrågningars URLer mot back-end-data via GETs, POSTs, AJAX, cookies, sessionslogik och kombinationer. Det är lättare att tillföra back-end till front-end än tvärtom, man måste både ha stenkoll och haft tid att designa alla flöden för att göra det senare.

Men som du säger jokohanho är du nu i "upptäcka-stadiet", så dessa tips gäller ju först när du drar igång på allvar

KurreKula,
Jag använder Java jag vet inget om Linq. Men det jag menar med att ändra i databasen, så pratar jag om datamodellen. Jag har svårt att se att om du ändrar datamodellen så uppdaterar Linq automatiskt all kodändringar så de går mot nya datatabellerna? Det låter som en revolution om det vore möjligt!

Exempel:
Antag att du har ett gäng tabeller som lagrar en person. En tabell har personnummer kopplat till namn. En annan har personnr kopplat till adress. Och en tredje har jobb kopplat till adress. Nu har du massa kod för att extrahera olika data och uppdatera dessa tabeller. Antag att du senare när du gjort klart logiklagret (dvs simuleringsmotorn) upptäcker att du vill inte alls ha dessa tabeller. Viss information var helt onödig, du vill ha helt andra tabeller (detta upptäcker du först mot slutet när simuleringmotorn är färdig). Då måste du ändra fett mycket i koden, designa om personklassen så den innehåller andra data och skapa nya databastabeller med nya kopplingar. Och sen måste du ändra i koden för att extrahera data och uppdatera dessa nya data eftersom du måste nu gå via nya datatabeller, inte de gamla tabellerna. Det är ett mastodontgöra. Ändrar man datamodellen så måste man ändra i tabellerna så de får helt nya kopplingar sinsemellan, och då ändras koden ordentligt.

Kan då Linq uppdatera all denna kod åt mig? Jag finner det svårt att tro? Men du menar att det är så, eller?

Vad gör Linq i DB sammanhang? Inte detta, väl?

Linq är ett sätt att mappa klasserna i databasen mot de klasser du har i koden mot de du har i databasen. Lägger man till en kolumn i databasen krävs det 2 ord till i koden för att den ska mappas mot ett fält i din klass. Sen visst, har man lagt upp det så att man måste ändra på massvis med ställen för att kunna ändra i databasen låter det ju som ett jävla jobb.

Men har svårt att se att man vill lägga upp det så att man behöver ändra på massvis av ställen för att ändra lite i databasen.

Självklart säger jag inte att linq uppdaterar all kod automatiskt ifall men bestämmer sig för att droppa massvis av tabeller etc. Det är snarare så att ifall man vill göra mindre ändringar är det väldigt enkelt. Håller helt klart med dig om att man ska tänka igenom allt så att man slipper göra massvis av ändringar, det är inte det jag säger emot. Grejen är att han just nu håller på att lära sig och då är en del i det att göra fel. Så man lär sig the hard way så att säga inget slår att ha fått erfara vilken pain in the ass vissa saker kan vara, då gör man aldrig om det ...

Antag att du har några klasser (som du lagrar som datatabeller). Du går via tabellerna för att extrahera olika information. Typ (1 är en klass, 2 är en annan klass, etc. Detta betyder att om du vill gå till tabell 3, så börjar du med 1, går till tabell 2, sen kan du hitta den information i 3 som du sökte)

1-2-3-4

Antag att 2-4-7

antag att 1-8-9-2

etc etc. Det är alltså flera tabeller som är kopplade på olika sätt till varandra. Så nu skriver du kod för att hitta information från tabell 4, när du har data från tabell 1:
...
....
...

Sen när du skrivit klart simuleringsmotorn så kommer du på att du behöver lite statistik, så du måste bryta upp de olika tabellerna. Så det blir inte 1-2-3-4. Nu måste du få in en statistik klass där i mitten
1-2-14-3-4
Och då måste du ändra i de andra tabellerna också, för stattistik klassen ska hämta information även från dem, så du lägger in kopplingar till klass 14 lite här och där.

Jag måste alltså ändra fett mycket i koden, för att alla klasser ska börja lagra statisitk. Så hur hjälper mig Linq i detta fall? Det blir ett hästjobb att ändra i all kod, eftersom datamodellen ändrats.

Därför föreslår jag att TS att börja med simuleringsmotorn, och sist gör man databasen. Därför att i början vet man inte vilka tabeller man vill ha. OCh jag har svårt att se att Linq hjälper i detta fall? I java finns det också grejer som att du plockar ut en Person() och instansierar den. Sen kör du bara getters och setters direkt på Personobjektet, utan att skriva något i SQL alls. Men hur hjälper det mig om jag ändrar datamodellen? Inte alls.