Ordrehåndteringssystem

Jeg vil foreslaa en anden database end Access.

Via internettet antyder at du skal satse paa en web app, som kan tilgaaes via enhver browser (du kan bruge en fact client og web services kald, men medmindre du har meget hoeje UI krav, saa er en web app simplere).

Almindelig ACID klares af enhver database som supporterer transaktioner.

Med hensyn til samtidig redigering saa check min artikel:
  http://www.eksperten.dk/guide/996
under "Long time locking".

Super artikel. Giver mange gode tips.

Jeg har før haft studenter job hos et firma, hvor man skulle benytte et php web interface de selv udviklede, herunder bl.a. ordre håndtering. Browser ventetider, manglende højreklik menuer, ingen tool tips. Den bruger oplevelse er jeg ikke selv så glad for.

Jeg havde egentlig også forestillet mig en mere-end-standard UI til applikationen.

1) Hvad kræver det helt konkret for at deploy en webservice på en hjemme-server?

2) Vil man blive irriteret over svartiderne, hvis man udfører sine DB kald gennem en Web Service.

Der må vel være et overhead ved at konvertere eksempelvis en select*-query's resultat på 15 kolonner x 100 linier til XML og sende det over en net forbindelse.

re 1)

Stort set ingen ting. Hvis man kan lave en web app, så kan man også lave en web service.

re 2)

Der er en del overhead. Men for mange former for brug betyder det ikke noget.

Generelt foretrækker man dog at expose sin business logic som services fremfor sin data access.

1) Skal man ikke have en webserver app installeret og konfigureret? Eller kan man nøjes med at installere VS.Net og så har man det, der skal bruges, til at gå online.

2) Et ordre håndteringssystem får svært ved at undvære en (filtreret) oversigt over ordrene i systemet og det er der jo ikke nødvendigvis ret meget business logic i.

Læser jeg mellem linierne, at i et system med eksempelvis mange databundne grids hos klienten, vil det være bedre, at lave et distribueret system med lokale databaser på klienterne, der kan synkronisere med serveren på udvalgte tidspunkter i stedet for real time.

Ingen overhead ved klient queries + mulighed for Offline Editing, men kræver til gengæld mere versionsstyring og konflikt håndering, samt længere tid for den store synkronisering.

re 1)

Baade web app og web service kraever en web server. Men en helt almindelig IIS er godt nok. ASP.NET skal ogsaa registreres hos IIS.

re 2)

Distribuerede data er normalt noget rod. Medmindre offline editing et et must have, saa ville jeg undgaa det.

Er enig i at distribuerede data er noget rod :-)

Smid et svar for indsatsen.

Til interesserede, så forsøger jeg mig med en offline udgave af ordrehåndteringssystemet, hvor hver klient opretholder deres egen lokale data, der synkroniseres med en koordinerende server gennem en webservice.

Hvis jeg kan slippe afsted med den løsning, så vil den være bedst til mit formål. Hvis jeg løber panden imod muren, så er hele indsatsen trods alt ikke spildt. Der er mange af de samme elementer i realtime og offline versionen.

svar