Lastenheft
HomeStorage
Version 0.2
Historie der Dokumentversionen
| Version | Datum | Autor | Änderungsgrund / Bemerkungen |
|---|---|---|---|
| 0.1 | 12.09.2018 | Sascha Patschka | Ersterstellung |
| 0.2 | 12.09.2018 | Sascha Patschka | Korrektur – rein EF Core anstatt Umweg über REST API |
Dieses Lastenheft beschreibt wie und in welchem Umfang die Aplikation HomeStorage erstellt wird, welche Features implementiert werden und wer an diesem Projekt hauptsächlich beteiligt sein wird.
Der User „MichaHo" alias Michael Hoffmann aus dem Forum vb-paradise.de hat den Wunsch geäußert bereits vorab in die Welt der Programmierung von WPF Applikationen unter Einhaltung des MVVM Patterns eingeführt zu werden, es gibt eine Tutorialreihe in diesem Forum welche allerdings noch länger nicht so weit fortgeschritten sein wird das hier das Thema MVVM angeschnitten werden kann. Das Projekt soll alle Vorteile aber auch Nachteile von MVVM aufzeigen und sohin so viele Funktionen welche für dieses Thema relevant sind beinhalten um einfach zu zeigen das sich MVVM auch lohnen kann da hierdurch auch viel Programmierarbeit geteilt und wiederverwendet werden kann.
MVVM – Model – View – ViewModel WPF – Windows Presentation Foundation VBP – VB Paradise Forum DAL – DataAccessLayer = Datenzugriffsschicht UWP – Universal Windows Plattform
Keine
| Rolle / Rollen | Name | Telefon | Bemerkungen | |
|---|---|---|---|---|
| Projektleiter | Sascha Patschka | patschka.sascha@live.com | ||
| 2. Projektleiter | Michael Hoffmann |
Noch keine
Noch keines
Ein korrektes (!!) MVVM Beispiel aufzuzeigen und zu zeigen das man mit MVVM alle Teile des Code wiederverwenden und austauschen kann. Die Struktur soll so aufgebaut werden das die Layer so gut wie möglich voneinander getrennt sind und die Application später umgebaut werden kann. Beispielsweise soll man später eine UWP App machen können welche dieselben Daten der Datenbank verwendet. Dies würde erfordern der DataAccessLayer getauscht wird da auch EF Core nicht direkt von einer UWP aus auf eine außenliegende DB zugreifen kann, dies soll mit dem geringsten Aufwand möglich sein weshalb die Layer so weit wie möglich runtergebrochen werden.
Gewisse Hauptfunktionen sollte die Applikation können (Siehe Punkt 3) damit diese ein vollständiges Programm darstellt da ich der Meinung bin das es keinen Sinn macht ein MVVM Beispiel zu erstellen welches zwar korrekt aufgebaut ist jedoch völlig sinnfrei ist. Alle implementierten Funktionen müssen Funktionieren und einen Sinn ergeben und nicht einfach wieder ein MVVM Beispiel abgeben welches im Grunde für nichts da ist und keinen Sinn ergibt. Davon gibt es bereits genug im Netz.
Ein Funktionierendes Beispiel für eine Anwendung zur Verwaltung von Lagerplätzen und als OpenSource Beispiel zum Lernen.
Programmierer
Es sollte alle gängigen Rechner ab Windows 10 32Bit und 64 Bit unterstützt werden.
https://materialdesignicons.com/ - XAML Icons programmableweb.com/category/barcodes/api – Liste von Barcode APIs
Schnell und einfach zu bedienen, einfache Ersteinrichtung und der Schwerpunkt auf Usability.
Grundfunktionen:
- .Verwaltung von Lagern, Sublagern, Lagerplätze
- .Artikelverwaltung verschiedender Typen mit Lagerplatzzurodnung
- .Attributverwaltung für Artikel (Ablaufdatum, Abmessung, Farbe usw.)
- .Schnittstellen für Artikelverwaltung als Pluginsystem (z.b. Barcodeabruf über API)
- .Notificationsystem (unterschreiten von Mindestlagermänge, Ablaufdatum usw)
- .Listengenerierung (Einkaufsliste, Obsoletliste)
- .Scanfunktion im Pluginsystem (Barcodescanner, NFC Scanner, QR Code Scanner)
- .Reportingfunktionen (Übersichten, Einkaufszettel, History)
Unterstützte Endgeräte:
- .Desktop WPF
| Nr. / ID | HS_01_01 |
Es soll EF Core zum Einsatz kommen wobei darauf geachtet werden muss das der Enduser sich für eine DB entscheiden können muss. MySQL, MS Sql, localDB usw. Der DAL welcher eine Referenz zu EF Core besitzt soll tauschbar sein, darf also EF Core oder dessen Context nicht nach Außen reichen soll aber dennoch über UnitTests testbar sein. Nur wenn keine EF Core Referenzen nach Außen gereicht werden ist es möglich die Datenzugriffschicht theoretisch jederzeit auszutauschen.
Dies wird im UnitOfWork Stil implementiert wodurch eine nahezu perfekte Abstrahierung erzielt wird.
Durch den Einsatz einer im UnitOfWork Stil aufgebauten Datenzugriffsschicht wird allerdings ein wenig von der Flexibilität von EF Core verlorengehen, jedoch nur minimal was vernachlässigt werden kann. Wichtig ist nur das Funktionen wie ChangeTracking, EagerLoading und andere Techniken von EF noch korrekt über mehrere Layer hinweg funktionieren sollten.
Wenn das ChangeTracking-System von EF genutzt wird sollte ein zukünftiger DAL dies anschließend auch unterstützen da sonst diese die BusinessLogic nicht mehr korrekt arbeiten könnte, was durch den Einsatz von SelfTracking Entitys erreicht werden kann und nur auf Modelebene implementiert werden müsste.
Bis EF 4 gab es Self Tracking Entitys vom MS.
Der Aufwand ist auf jeden Fall gerechtfertigt da keine anderen Layer mehr einen Verweis auf EF haben müssen. Erstimplementierungsaufwand ca. 4 Stunden.
Ausstehend!
Keine