Hmm das klingt nach dem typischen Fass ohne Boden.
Eine Frage zum Anfang, Projekt heisst du entwickelst das nur für Dich oder das soll mal was wirklich produktives werden ? (Einsatz in der "real" World?)
Wichtig ist halt das du Dir erst mal ein Backend/Schnittstellen zusammen baust um deine Abläufe irgendwie abzubilden. Als 0815 und Hobbyentwickler würde ich das halt alles mit PHP, MYSQL lösen. Kommunikation per REST und Datenaustausch schön per JSON im Idealfall auch noch alles verschlüsselt.
Datenbank, da musst du halt selber noch mal schauen wie Kleinteilig es werden soll. (Ware würde ja dann ein Mietauto sein -> Typ, Farbe, ect pp)
1 Tabelle -> Kundendaten (Kunde muss sich ja registrieren und anmelden können)
1 Tabelle -> Aufträge (je nach
1 Tabelle -> Mitarbeiter (um eventl nach zu vollziehen, welcher Mitarbeiter hat wieviele Aufträge bekommen, abgeleht ect pp)
div Kreuztabellen um die n:m Beziehungen herzustellen
Zitat
Kunde muss über die Homepage (Formular) eine bestellung absetzen können.
Kunde muss über eine Handy-App eine Bestellung absetzen können.
Homepage kommuniziert über Frontend mit deinem Backend (Formulare ect pp)
App würde im Grunde das selbe über eine definierte Schnittstelle (REST irgend etwas anderes machen)
-> Hier würde dann das Thema Datensicherheit, Verschlüsselung ect ebenfalls eine Rolle spielen.
Zitat
Chef erhält info über Firmen-App, dass ein neuer Auftrag eingegangen ist.
-> sobald Kunde Auftrag auslöst und die gewünschten "Auftragsdaten" in die Datenbank übermittelt wurden, kannst
du hier unterschiedlich weitermachen.
old school und böse, ist das sogenannte Polling. D.h. App vom Chef fragt in einem definierten Interval beim Server an ob neue Aufträge vorliegen und
zieht sie sich aufs Handy. Da Chef keinen Auftrag verpassen möchte, müsste hier das Interval relativ klein sein -> nicht sehr effizient.
stromsparender und Akkufreundlich wäre hier eine PUSH Lösung, Google Cloud Messages sind ja ein kostenloser Service, diverse andere Anbieter (Enterprise Services gibt es auch) -> Pushnachrichten müssen ja nicht immer "Nachrichten" sein, das können auch eigens definierte Events sein. Sprich du kannst Dir eine eigene Kommunikationstruktur (zb per JSOn einfallen lassen und damit operieren).
Sprich nach dem die Datenbank gefüllt wurde, wird der App des Chef entweder der komplette Aufrag gepushed (GCM Nachrichten haben einen Payload von 4kb) oder du versendest nur ein Event an die App "Hallo neuer Auftrag" und das Handy holt sich die Daten selber vom Server.
Zitat
Chef kann Auftrag weiterleiten ODER selbst fahren.
-> wäre dann die Auftragsbestätigung und wieder eine Backendaufgabe, Chef klickt in der App ja und dein Backend kümmert sich um den Rest (Kunde wird informiert ect pp)
-> Wenn Chef den Auftrag weitervermitteln will, dann z.b. wieder über den Push Weg
Zitat
Mitarbeiter kann die vom Chef weitergeleiteten Aufträge ANNEHMEN oder ABLEHNEN (wobei
der chef über auswahl informiert werden muss)
-> siehe Chef.
Das kann im Grunde die selbe App sein. Mitarbeiter meldet sich mit seinem Mitarbeiter Login an und hat damit Zugriff auf bestimmte Funktionalität.
Mitarbeiter - Chef hat also alle Features
Mitarbeiter - Mitarbeiter (Arbeitsbiene) kann halt nur Aufträge annehmen oder ablehnen.
Kunden und Mitarbeiter App zu vereinen ist natürlich möglich, ich denke aber eine Trennung wäre sauberer.
Zitat
Der webserver+datenbank muss auf .net/c# schiene gebastelt werden, was wiederrum zur frage führt
wie die app mit dem webserver+datenbank kommunizieren muss?
REST
