Ich bin echt ein begeisterter Entwickler seit vielen Jahren und hier wird man echt extrem schnell ausgebildet. Also ich mag deine Arbeit, zieh meinen Hut und werde mir noch viele Videos von dir ansehen. Respekt!
Hey du, ich höre dir gerade eine Minute zu und bemerke schon: oho. du hast bestimmt etwas auf m Kasten! :D Ich freue mich, dass ich dich hier gefunden habe, denn Software-Architektur ist für mich ein brennendes Thema. Danke!
Hallo David, danke dir vielmals für die tollen Videos. Mich hat es schon immer interessiert was genau der Unterschied zwischen den Begriffen wie Modulen, Komponenten, Assemblies, etc. sind, hatte jedoch immer Zweifel davor online zu googeln oder Forumsbeiträge zu dem Thema zu lesen, weil ich einfach nicht sicher sein konnte ob das nun wirklich stimmt oder nicht... Zum Glück habe ich deinen Kanal gefunden, wo die Dinge einfach so klar und nachvollziehbar erklärt werden, dass am Schluss keine Fragezeichen oder Zweifel mehr offen bleiben. Danke dafür!
Vielen Dank für dieses tolle Video! Genial erklärt und dann noch super Beispiele welche die Thematik verständlich machen - Abo ist dir sicher und werde gerne deine anderen Videos noch anschauen. Heb dir Sorg!
Tolles Video! Was spricht deiner Meinung nach dagegen, die Komponenten nach Schichten aufzuteilen? Die von dir aufgezeichneten Komponenten sind dann im Logik Layer, der Data Store im Daten Layer
Hallo Christoph, soweit gar nichts. In dem hier vorgestellten Ansatz ist das auch implizit geschehen - zunächst die technische SRP-Aufteilung und dann die Fachliche. In der Projektmappe später hat man meist Ordner für die einzelnen Schichten um das ganze besser zu organisieren. Das ist einer der Vorteile von Software Architektur mit Komponenten. Gruß David
@David Tielke: Hast du mit dem CPU-Beispiel sogar eher ein schlechtes Beispiel gewählt? Intel als Hersteller wechselt alle 2-3 Jahre ihren Sockel. Wenn dies soch in einer Software wäre, dass ein Zulieferer immer seine Module ändert, müsste dafür ja in der Software ein ein Adapter geschaffen werden und dafür dürften dann irgendwann Interfaces nicht (immer oder mehr) ausreiche, so dass an so etwas wie ein "Abstraction Layer" zu denken ist, um auch noch die CPU-Sockel für AMD mit unter einen Hut zu bekommen. Hier wäre mal die Frage, was für eine Idee in solch einen Fall vorsehen würdest. Danke.
Mal eine Frage zu dem Beispiel: Das Repository übernimmt die Ladefunktionalität aus der DB, wird aber nicht in der Form direkt genutzt? z.B. Wenn ein Objekt aus der DB geladen wird, landet es erstmal im Repository. Das Repository befindet sich dann im Manager. Also muss der Manager auch eine Ladefunktion haben, die dann in der Form enthalten ist. Ist das dann nicht gedoppelt oder verstehe ich das Beispiel falsch?
Hi. Was ist denn nun der Unterschied zwischen Komponent und Modul? Im Video erwähnst du "Komponenten sind Systeme, Systeme sind Module". Mir fehlt die Auflösung des Begriffs Modul. Würde mich freuen, wenn du kurz darauf eingehen könntest. Danke!:)
Hey Rafael, gerne: Du sagst es ja selbst, Komponente = System = Modul, d.h- es ist alles dasselbe. Damit wird ein abstraktes Konzept beschrieben was nach dem EVA-Prinzip funktioniert. Also ist eine Komponente, Modul oder System eine abstrakte Darstellung einer Methode, einer Klasse, einer Kompontente, einer Schicht, eines Dienstes, einer Anwendung. Gruß David
Echt spannende Videoserie. Mich würde an deinem Repository-Ansatz interessieren wie du im Fall von Entity Framework Change Tracking betreibst oder ob das dann generell wegfällt? Meine Gedanke war ein "long living"-Context in der Repository Implementierung, die Methoden Add, Remove, Save gehen dann immer über den Context, zusätzlich hat man dann noch die HasChanges Methode. Ich vermute auch, dass du dann jegliche Async Implementierung durch den IQueryable Ansatz in die xyzManager Klassen packst oder?
Hey Waldemar, vielen Dank, schön das Dir meine Videos gefallen. Change-Tracking ist ein Konzept und Du solltest Dir immer überlegen, ob Du das Konzept auch hinter der Schnittstelle (IRepository) verwendest. Wenn Ja, müssen alle potenziell zukünftigen Implementierungen das ebenfalls unterstützen. Diese Konzepte sind leider nicht Bestandteil des Kontraktes IRepository, sondern ist mehr oder weniger ein impliziter Teil davon, damit ist es auch SQ-Sicht natürlich immer kompliziert. Ich verzichte deshalb immer vollständig auf ChangeTracking und arbeite mit einem zustandslosen Datenkontext und detached Entities (im Web bringt Dir das eh nichts) Hoffe das hilft Dir weiter, habe Deine Frage aber mal als VideoIdee notiert - mal schauen wann wir Zeit dazu finden :) Gruß David
Hey David, echt super Video. Wie immer einfach und verständlich erklärt. Könntest du in einem zukünftigen Video die drei verschiedenen Architekturen vergleichen an einem einfachen Beispiel in einer Visual Studio Solution? Mich würde brennend interessieren wie z.b. eine ML-A als Solution aufgebaut ist im Gegensatz zu einer K-A. Gruß Daniel
Hallo Daniel, danke für Dein Feedback, schön wenn Dir meine Videos gefallen. Deine Idee mit dem Video nehme ich mal in meine Liste auf, super Idee, danke dafür! Gruß David
@@DavidTielkedann müsste man so weit differenzieren und sagen dass die physische Schnittstelle sogar die einzelnen pins bei AMD (PGA) bzw Pads bei Intel (LGA) sind welche theoretisch auch manuell einzeln verlötet werden könnten und damit unabhängig vom Sockel immer "kompatibel" sind. z.b. passen auch pciex1 Karten in einen AGP Slot. Mir ist klar was gemeint ist dennoch denke ich der Vergleich hinkt etwas, natürlich nicht weiter hinderlich für das Thema dieses Videos/dieser Reihe ich dachte nur es Mal anzumerken. LG
Der Sinn hier ist es ja, dem Zuhörer ein vergleichbares Konzept aus einer anderen Welt zu präsentieren, was auf dieser abstrakt geschilderten Ebene erlaubt das ganze dann in die konkrete Softwareentwicklung zu projizieren. Der Sinn der Schnittstelle ist es, dass nur die Elemente genutzt werden können, die diesen Kontrakt auch implementieren. Genau das machen CPU Sockets, sie verhindern dann ein AMD-CPU auf ein Intel-Board gesteckt werden kann - das ist die Analogie. Was Du mit dem rumgelöte sagen möchtest, verstehe ich nicht ganz weil das theoretisch vielleicht richtig ist, aber fernab des Contextes dieser Analogie ist. Aber ich nehme für mich mit, dass es vereinzelt Personen gibt, die diese Analogie nicht passend finden ;) Gruß David
Ich bin echt ein begeisterter Entwickler seit vielen Jahren und hier wird man echt extrem schnell ausgebildet. Also ich mag deine Arbeit, zieh meinen Hut und werde mir noch viele Videos von dir ansehen. Respekt!
Hey du, ich höre dir gerade eine Minute zu und bemerke schon: oho. du hast bestimmt etwas auf m Kasten! :D Ich freue mich, dass ich dich hier gefunden habe, denn Software-Architektur ist für mich ein brennendes Thema. Danke!
Hey Timo,
danke für das Lob - schön das Du dabei bist :)
Gruß David
Wollte eigentlich nur kurz was über Komponentendiagramme anschauen und bin hierrauf gestoßen (was noch mehr inhalt hatte). Echt gut, danke!
Du hast mich durch mein Modul Softwareentwicklung gebracht danke mein bester !
Hallo David, danke dir vielmals für die tollen Videos. Mich hat es schon immer interessiert was genau der Unterschied zwischen den Begriffen wie Modulen, Komponenten, Assemblies, etc. sind, hatte jedoch immer Zweifel davor online zu googeln oder Forumsbeiträge zu dem Thema zu lesen, weil ich einfach nicht sicher sein konnte ob das nun wirklich stimmt oder nicht...
Zum Glück habe ich deinen Kanal gefunden, wo die Dinge einfach so klar und nachvollziehbar erklärt werden, dass am Schluss keine Fragezeichen oder Zweifel mehr offen bleiben. Danke dafür!
Super Video, hat mir im Modul Software Engineering gut weitergeholfen 🙏🏽
Hey,
sehr cool - Glückwunsch und noch viel Erfolg im Studium.
Gruß David
Danke!! Hat echt Spaß gemacht!
Vielen Dank für dieses tolle Video! Genial erklärt und dann noch super Beispiele welche die Thematik verständlich machen - Abo ist dir sicher und werde gerne deine anderen Videos noch anschauen. Heb dir Sorg!
Tolles Video!
Was spricht deiner Meinung nach dagegen, die Komponenten nach Schichten aufzuteilen? Die von dir aufgezeichneten Komponenten sind dann im Logik Layer, der Data Store im Daten Layer
Hallo Christoph,
soweit gar nichts. In dem hier vorgestellten Ansatz ist das auch implizit geschehen - zunächst die technische SRP-Aufteilung und dann die Fachliche. In der Projektmappe später hat man meist Ordner für die einzelnen Schichten um das ganze besser zu organisieren. Das ist einer der Vorteile von Software Architektur mit Komponenten.
Gruß David
@David Tielke: Hast du mit dem CPU-Beispiel sogar eher ein schlechtes Beispiel gewählt?
Intel als Hersteller wechselt alle 2-3 Jahre ihren Sockel. Wenn dies soch in einer Software wäre, dass ein Zulieferer immer seine Module ändert, müsste dafür ja in der Software ein ein Adapter geschaffen werden und dafür dürften dann irgendwann Interfaces nicht (immer oder mehr) ausreiche, so dass an so etwas wie ein "Abstraction Layer" zu denken ist, um auch noch die CPU-Sockel für AMD mit unter einen Hut zu bekommen.
Hier wäre mal die Frage, was für eine Idee in solch einen Fall vorsehen würdest. Danke.
Superangenehme Sprechstimme 🙋🏼♀️
Danke!
Mal eine Frage zu dem Beispiel: Das Repository übernimmt die Ladefunktionalität aus der DB, wird aber nicht in der Form direkt genutzt? z.B. Wenn ein Objekt aus der DB geladen wird, landet es erstmal im Repository. Das Repository befindet sich dann im Manager. Also muss der Manager auch eine Ladefunktion haben, die dann in der Form enthalten ist. Ist das dann nicht gedoppelt oder verstehe ich das Beispiel falsch?
Super Video! Die Einblendung der Playlist ist leider nicht mehr vorhanden, könntest du mir hier da nochmal den Link drunter Posten bitte? Danke!!
Hi.
Was ist denn nun der Unterschied zwischen Komponent und Modul? Im Video erwähnst du "Komponenten sind Systeme, Systeme sind Module". Mir fehlt die Auflösung des Begriffs Modul. Würde mich freuen, wenn du kurz darauf eingehen könntest. Danke!:)
Hey Rafael,
gerne: Du sagst es ja selbst, Komponente = System = Modul, d.h- es ist alles dasselbe. Damit wird ein abstraktes Konzept beschrieben was nach dem EVA-Prinzip funktioniert. Also ist eine Komponente, Modul oder System eine abstrakte Darstellung einer Methode, einer Klasse, einer Kompontente, einer Schicht, eines Dienstes, einer Anwendung.
Gruß David
Danke für den Beitrag. Ist aber nicht das Mainboard der Provider der Schnittstelle und die Grafikkarte der Consumer?
Jepp, hab ich einmal vertauscht - sorry :)
Gruß David
👍👍
Echt spannende Videoserie.
Mich würde an deinem Repository-Ansatz interessieren wie du im Fall von Entity Framework Change Tracking betreibst oder ob das dann generell wegfällt?
Meine Gedanke war ein "long living"-Context in der Repository Implementierung, die Methoden Add, Remove, Save gehen dann immer über den Context, zusätzlich hat man dann noch die HasChanges Methode.
Ich vermute auch, dass du dann jegliche Async Implementierung durch den IQueryable Ansatz in die xyzManager Klassen packst oder?
Hey Waldemar,
vielen Dank, schön das Dir meine Videos gefallen.
Change-Tracking ist ein Konzept und Du solltest Dir immer überlegen, ob Du das Konzept auch hinter der Schnittstelle (IRepository) verwendest. Wenn Ja, müssen alle potenziell zukünftigen Implementierungen das ebenfalls unterstützen. Diese Konzepte sind leider nicht Bestandteil des Kontraktes IRepository, sondern ist mehr oder weniger ein impliziter Teil davon, damit ist es auch SQ-Sicht natürlich immer kompliziert. Ich verzichte deshalb immer vollständig auf ChangeTracking und arbeite mit einem zustandslosen Datenkontext und detached Entities (im Web bringt Dir das eh nichts)
Hoffe das hilft Dir weiter, habe Deine Frage aber mal als VideoIdee notiert - mal schauen wann wir Zeit dazu finden :)
Gruß David
Hey David, echt super Video. Wie immer einfach und verständlich erklärt.
Könntest du in einem zukünftigen Video die drei verschiedenen Architekturen vergleichen an einem einfachen Beispiel in einer Visual Studio Solution?
Mich würde brennend interessieren wie z.b. eine ML-A als Solution aufgebaut ist im Gegensatz zu einer K-A.
Gruß
Daniel
Hallo Daniel, danke für Dein Feedback, schön wenn Dir meine Videos gefallen. Deine Idee mit dem Video nehme ich mal in meine Liste auf, super Idee, danke dafür!
Gruß David
Die Schnittstelle von CPU zu Mainboard ist NICHT der Sockel sondern der Chipsatz
Die physikalische Schnittstelle ist der Sockel - was die logische ist, war nicht gemeint - ich denke dazu gehört nicht nur der Chipsatz!
Gruß David
@@DavidTielkedann müsste man so weit differenzieren und sagen dass die physische Schnittstelle sogar die einzelnen pins bei AMD (PGA) bzw Pads bei Intel (LGA) sind welche theoretisch auch manuell einzeln verlötet werden könnten und damit unabhängig vom Sockel immer "kompatibel" sind.
z.b. passen auch pciex1 Karten in einen AGP Slot.
Mir ist klar was gemeint ist dennoch denke ich der Vergleich hinkt etwas, natürlich nicht weiter hinderlich für das Thema dieses Videos/dieser Reihe ich dachte nur es Mal anzumerken.
LG
Der Sinn hier ist es ja, dem Zuhörer ein vergleichbares Konzept aus einer anderen Welt zu präsentieren, was auf dieser abstrakt geschilderten Ebene erlaubt das ganze dann in die konkrete Softwareentwicklung zu projizieren. Der Sinn der Schnittstelle ist es, dass nur die Elemente genutzt werden können, die diesen Kontrakt auch implementieren. Genau das machen CPU Sockets, sie verhindern dann ein AMD-CPU auf ein Intel-Board gesteckt werden kann - das ist die Analogie. Was Du mit dem rumgelöte sagen möchtest, verstehe ich nicht ganz weil das theoretisch vielleicht richtig ist, aber fernab des Contextes dieser Analogie ist. Aber ich nehme für mich mit, dass es vereinzelt Personen gibt, die diese Analogie nicht passend finden ;)
Gruß David