Laden...

Projektstruktur: Aktuell Desktop, später Web

Erstellt von fichz vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.270 Views
F
fichz Themenstarter:in
26 Beiträge seit 2013
vor 5 Jahren
Projektstruktur: Aktuell Desktop, später Web

Guten Tag,

ich habe eine Frage zur Projekt Architektur meines nächsten Projektes und würde mir gerne euren Rat bzw. eure Erfahrungswerte dazu anhören.

Folgendes ist gegeben/gewünscht:
Ich soll eine Webapplikation erstellen wo simple CRUD-Funktionen zur Verfügung stehen sollen. Die Daten werden über einen SQL-Server bereitgestellt und zurückgespeichert.
Das Problem: Der Wissenstand damit ich eine Webapplikation erstellen kann reicht leider noch nicht aus - Schulung wird folgen.
Da die Applikation aber nur intern laufen soll und dies auf einem Windows Tablet sein wird die Applikation vorerst als Desktop Anwendung erstellt.

Ich will nun das Projekt so anlegen, dass ich zuerst die Desktop Applikation erstelle und später, wenn ich genug "Web-Fit" bin, zusätzlich (auch für mich als "Übung") eine Webapplikation hinzufüge.

Meine Idee wäre nun:
Die Projektmappe enthält

  • eine Klassenbibliothek wo der komplette Datenzugriff stattfindet. Speziell will ich das über das Repository Pattern lösen
  • ein Windows Forms bzw. WPF-Projekt welches die Desktop Applikation darstellt und auf die Klassenbibliothek für den Datenzugriff zugreift
  • später dann ein ASP - MVC Projekt welches auch auf die gleiche Klassenbibliothek zugreift und dies dann halt als Webapplikation ausgeführt werden kann

Ist dieser Ansatz OK oder empfehlt ihr hier einen anderen/besseren Weg?

Falls noch etwas unklar ist bitte einfach fragen.

lg
fichz

16.806 Beiträge seit 2008
vor 5 Jahren

Der Ansatz ist prinzipiell richtig; ganz normale [Artikel] Drei-Schichten-Architektur

Es lohnt sich aber auch detallierter zu recherchieren; so solltest Du alle Abfragen asynchron via async/await umsetzen, da dies in ASP.NET Core in Zukunft pflicht wird (wie es auch schon bei mobilen Anwendungen und Tablet-Anwendungen der Fall ist).

Ansonsten kann man recht wenig an Infos beitragen.

F
fichz Themenstarter:in
26 Beiträge seit 2013
vor 5 Jahren

Hallo Abt!

Das mit den asynchronen Abfragen werde ich natürlich beherzigen.

Dann werde ich eine Daten + Business Schicht (Projekte) erzeugen wo dann die unterschiedlichen UI-Projekte gemeinsam drauf zugreifen können.

Danke für die prompte Antwort!

lg
fichz

16.806 Beiträge seit 2008
vor 5 Jahren

Wenn Du einen sehr modernen Ansatz wählen willst, und das nicht zu weit ist, dann schau Dir direkt CQRS und Reactive Extensions an.
Beides kommt aus der Cloud-Welt und findet mittlerweile auch rapide seinen Einsatz in der Desktop-Welt.

Beides Mechanismen, die eine sehr saubere Struktur und eine sehr hohe Modularisierung zulassen.
IMediatR ist hierbei eine sehr schlanke In-Process Lib für CQRS. (siehe mein Beispiel auf GitHub).

F
fichz Themenstarter:in
26 Beiträge seit 2013
vor 5 Jahren

Hallo Abt!

Werde ich mir bei Gelegenheit mal ansehen, kann ich aber wahrscheinlich in diesem Fall noch nicht machen, da hier etwas Zeitdruck herrscht.

Zur 3-Schichten-Architektur hätte ich aber noch Fragen:

Ich habe jetzt ein .Data - Projekt für den DAL und ein .Service - Projekt für die BL erstellt.
Irgendwie habe ich aber Schwierigkeiten wo ich nun meine konkreten Klassen implementieren soll/muss.

Speziell:

  • Datenklassen (POCOs) -> Data?
  • Repositories -> Service?
  • Implementierung des UnitOfWork?

Ist der BL nur dazu da die Daten aus dem Data-Projekt zu lesen/speichern - quasi als Schnittstelle?

Stehe hier ein wenig auf dem Schlauch...

lg fichz