Hej!

Skulle behöva lite tankehjälp med OOP och vad man skall tänka på när man skall bygga upp ett system.

Jag skall göra ett kassasystem där man både kan hyra och köpa artiklar.
Tanken är att man skall administrera systemet centralt och att databasen skall ligga på en central server. Därför tänkte jag använda ASP.NET då det är flera butiker som skall använda systemet.

Tabeller jag tänkte använda:
<ul class=important>
<li>Grunddata för alla artiklar
<li>Butiksartiklar (alla butiker har ju inte samma utbud)
<li>Lagring av alla transaktioner
<li>Kunder (behövs vid uthyrning)
<li>Leverantörer
</ul>

Jag behöver också en del sidor som t.ex för uthyrning/försäljning, återlämning av hyrda artiklar, artikelregister, administrering, kunder, leverantörer o.s.v.

Man kanske kan ha uthyrning/ försäljning och återlämning på samma sida med olika lager som görs synliga berooende på om det gäller en återlämning av uthyrd artikel eller en uthyrning/försäljning?

Tanken är också att man i en och samma textruta skall kunna skriva in
<ul class=important>
<li> Personnummer. Info om kunden skall visas
<li> Artikelnummer. Artikel skall läggas till i listan
<li> Text. En lista varifrån man kan välja artiklar eller kunder visas (man skall först välja om det är kunder eller artiklar som skall visas)
</ul>

När man slår in ett artikelnummer skall det också göras en koll om artikeln är uthyrd och i så fall skall återlämningsmenyn visas automatiskt.

Frågan är hur skall man göra? Vilket är bäst?
Skall man börja med layouten eller kodningen?
Vilka klasser behöver man?
Skall man använda Sessionsvariabler, lagra objekt i den med information om kunden,butiken?
Webforms? WebServices? eller ngt annat.

Jag har inte så stor erfarenhet av ASP.Net så jag är tacksam för alla förslag, funderingar, rekomendationer, exempel, hänvisningar och dyligt som jag kan få.


tackar på förhand

Hej, bygg lösningen i ett antal lager

Dataaccess - där du hämtar / uppdaterar / skapar data (om du gör denna fiffigt kan du byta databas utan problem framöver)
Facade - där du authentiserar, loggar, kontrollerar data
GUI - som endast pratar med facade-klasserna

Data bör du transportera i typade dataset för att vara "framtidssäker" om du ev vill skapa webbtjänster o dyl framöver

När jag börjar på nya projekt brukar jag numera alltid börja med databasstrukturen. Använd till exempel ett program som Visio 2003 Professional, där man kan lägga upp tabeller, göra kopplingar och sedan direkt exportera hela strukturen till SQL Server. Då får man både en bra översyn på strukturen - som man sedan kan skriva ut och ha och titta på när man bygger DA-lagret - och hela databasen blir klar utan den tråkiga inmatningsprocessen. Allt krångel hamnar därmed i Visio, där det är lätt att ändra sig och bygga om. Tänkar man igenom sin databasstruktur ordentligt brukar det bli rätt i slutändan med.

Sedan om du börjar med layouten eller kodandet spelar väl egentligen ingen roll. Jag kan tycka att det är smidigt om man gör klart hela DA-lagret innan man börjar med layout, eftersom jag annars kodar funktionaliteten för formulären samtidigt som jag gör designen. Då måste jag hela tiden bryta det jag håller på med för att lägga till en tabell eller en fråga i DA-lagret...

Högst amatörmässiga tips från mig som är självlärd, men något kanske går att använda ? :P

bygger man datamodellen först så är det lätt att man bygger in sig i ett hörn.

Det är mycket bättre att modellera sin applikations affärslager utifrån den domänkunskap man kan tillskaffa sig, när man gjort det så får man en logisk vy över hur applikationen måste fungera och kan ta beslut om datalagring, formulär och andra infrastruktur bitar runtomkring.

Det är möjligt att det finns bättre sätt; mina projekt hittills har varit ganska små. Jag förstår dock inte riktigt hur du menar...

Ett kassasystem där databasen skall ligga på en central server och flera butiker som skall använda systemet. Låter lite farligt. Vad händer om en butik tappar anslutningen? Det är viktigt att ett kassasystem skall kunna arbeta offline för att senare synkronisera.
Jag ser ASP.NET som ett hinder. Jag tycker du utvecklar en "rik" applikation.

Detta är en verksamhetskritisk applikation. Ett avbrott påverkar verksamheten direkt. För mig skulle jag se att kassasystemet var klientserver baserat med möjlighet att ha en lokal databas hos butiken eller klienten med artiklar. Kunna spara ordrar lokalt för att senare synkronisera dem.

Om du väljer att utvecklar i ASP.NET skulle det innebära en webserver i varje butik. Det anser jag ge för mycket administration och komplicerad lösning. Då är det mer lämpligt med en riktig klient skriven i t.ex. .NET eller Java. Synkronisera mot en server vilket kör en webservice för applikationen.

Jag tycker inte man skall utveckla en applikation från en plattform. Utan välja blatform utifrån behovet applikationen skall uppfylla. Detta tror jag ger bättre applikationer.

Tanken var att man skall kunna administrera databasen centralt och lägga upp nya artiklar o.s.v.
Man skall även kunna se om en artikel som är slut på lagret finns i en annan butik och i så fall reservera den till kunden.
Hur skall man göra det utan en central server?

Jag är för central server. Men det måst finnas möjlighet att arbeta lokalt om man tappar anslutningen.

Hillqvist,

Är med på din bana.. att kunna jobba disconnected är viktig. Kanske använda ett meddelande baserat system så som MSMQ för detta.

Det finns idag ett klientbaserat system (skrivet i VB6) i varje butik. Det är kopplat mot en lokal server.
Att de vill köra centraliserat är förutom möjligheten till att reservera/boka varor som finns i en annan butik och att lägga upp nya artiklar även att kunna köra statistik för alla butiker tillsammans och även butikerna för sig.
Man skall alltså kunna ha kontoret i en av butikerna (eller någon annanstans) och därifrån administrera hela systemet.
Jag har också funderat över hur man gör om man tappar anslutningen.
Ja håller med dig Andreas att det är en "verksamhetskritisk applikation" och har också varit inne på tanken med ett lokalt system med möjllihet att koppla sig (synkronisera) mot en central server.
Problemet är att jag inte vet (för lite kunskap) hur man gör för att synkronisera mot en annan server.
Hur skulle ni ha gjort?
Några exempel och/eller hänvisning till var man kan få information om en sådan lösning.

Någon som har förslag eller tips om artikel om att synkronisera mot en annan server?

Hej Krister
Jag tycker att Andreas tänker rätt och att man måste tänka på synkronisering mellan de lokala servrar och central server.
Du skall först välja DB för central server som kan ’prata’ med lokala DB. Och de måste vara en riktig DB (ingen Access förstås) som ska göra hela jobbet dvs. synkronisering.
Om du väljer SQL server så finns där ett antal finesser såsom SQL Jobb Agent. Man skapar ett jobb -uppdatering utav lokala DB som ska sättas igång varje timme exempelviss och skicka/hämta senaste informationen.

Här är länken till deras forum: http://www.sqlteam.com/forums/

/Marina

Hur gör man om man endast skall uppdatera poster som skiljer sig åt mellan tabellerna?

Hej Krister,

1. Ta reda på vilka DB som är lokala. Bygg upp din centrala DB enligt det här DB modellen. Lägg till en tabell ’Butik’ till central DB som ska ha all information om Butiker, koppla ButikID till resten av information.
2. I tabellen ’Butiksartiklar’ för både DB (lokala och central) lägg till en fält ’Senast uppdaterad info’
SQL commandot ser ut ungefär så har:
alter table Butiksartiklar add timeupdate datetime null
Då har du info både här och där och senast uppdaterad datum. I koden behöver du veta bara det. Om datum skiljer sig då uppdatera den som är gammal.

/Marina