Laden...

In wie weit man Abhängigkeiten auflösen sollte

Erstellt von zero_x vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.310 Views
zero_x Themenstarter:in
1.044 Beiträge seit 2008
vor 13 Jahren
In wie weit man Abhängigkeiten auflösen sollte

Hallo zusammen,

in diesem Video wird gezeigt, wie man Sachen von einander lösen kann. Ich persönlich finde den Ansatz ein wenig extrem, aber trotzdem sehr gut. Die Vorteile, die sich daraus ergeben, sind doch im Gegensatz zu dem ersten Beispiel um einiges besser. Erst wie gezeigt, wie man es klassisch programmiert, ohne groß Wert auf IoC/DI - mehr oder weniger - zu legen dann wie man es nach IoC/DI programmiert. Akzeptabel finde ich beide Varianten, tendiere aber zur Möglichkeit, dass am Ende des Videos gezeigt wird. Ohne jetzt auf die Vor- und Nachteile einzugehen, habe ich mir Gedanken gemacht, in wie weit man das treiben darf.

Mein erster Gedanke ist, dass die Console eine Visualisierung darstellt. Diese Visualisierung ist keine echte, sondern eher eine Möglichkeit etwas auf einer gewissen Art und Weise darzustellen. Der Begriff "Visualisierung" möchte ich an dieser Stelle verwenden, vielleicht ist der Begriff auch ein wenig überzogen, passt aber gut. Neben einer Console kann so gut auch eine UI existieren. Die UI wäre genau so wie die Console ein Visualizer und stellt dem User eingeben zur Verfügung. Ein- und Ausgaben sind also kein Problem. Alles, was die Console kann, kann auch die UI. In einer gewissen Hinsicht hat die UI mehr Möglichkeiten, aber das ist kein Problem. Nehmen wir einen Button. Statt eines Buttons kann in der Console eine Aufforderung eines Textes erscheinen. Die Aufforderung eines Textes in der Console ist also gleichzustellen mit dem Button auf der UI. Der Button auf der UI nimmt etwas in gegen, wie auch die Console.

Überspitzt würde ich sagen, dass man alles, was auf der Console stattfindet auch auf einer UI programmiert werden kann. Im Grunde kann man die UI und die Console abstrahiert angesehen werden. Genau an diesem Punkt der Abstraktion frage ich mich, ob das ein guter Ansatz für ein Projekt ist. Geht man noch einen Schritt weiter, kann man sagen, dass man mit einer bzw. mehreren Libraries einmal eine UI und eine Console gleichzeitig programmieren kann.

Was ich zum Ausdrück bringen möchte: Je extremer man etwas programmiert, desto mehr Flexibilität steht einem in Nachhinein zur Verfügung. Mit diesem Extrem meine ich ein solches extrem wie in dem Video. Mein Gedankengang ist vielleicht kein gutes Beispiel, aber vorstellbar. Noch überspitzer kann man auch weitergehen. Man stelle sich einfach mal große Projekte vor!

Patterns wie MVC, MVP oder MVVM machen nichts mehr, als Daten auf irgendeiner Weise auf einer UI darzustellen. Hier möchte ich genauer auf das MVVM-Pattern eingehen. Das ViewModel ist das Herzstück, was zwischen Model und View steht und die Daten aufbereitet. Man ist also zwingend an das Konzept von WPF bzw. der View gebunden. Man könnte es jetzt so implementieren, dass die View sich das von mir beschriebene Konzept(s. oben) aufgebaut. Egal in welcher Lage sich das ViewModel befindet, es funktioniert. Der Vorteil ist, dass es noch flexbilber ist. Diesen Gedanken möchte ich an dieser Stelle nicht weiter fortführen, da dies nochmals eine Diskussion für sich ist.

Mein bzw. meine Gedanken sind wahrscheinlich ein wenig unverständlich, aber projiziert man es auf ein konkretes Projekt und einem festen Konzept, hat man doch mehr davon. Jetzt möchte ich euch fragen: Was meint ihr? Ist mein Gedankengang gerechtfertigt?

zero_x

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

du schreibst viel, sagst aber im Prinzip wenig 😃 Das Video beschreibt nichts anderes als die Trennung von Funktionalität und Präsentation. Und das wird schon immer so gemacht, egal ob man irgendwelche speziellen Patterns benutzt oder DI um zur Laufzeit noch zu entscheiden welche Funktionalität ausgeführt wird. Das ist nichts neues und da kann man immer sagen das man es machen muss. Deine Gedanken zur Console und UI (wobei die Console natürlich auch ein UI ist - verstehe nicht warum du das trennst) wurden schon vor Jahrzehnten gedacht.

Geht man noch einen Schritt weiter, kann man sagen, dass man mit einer bzw. mehreren Libraries einmal eine UI und eine Console gleichzeitig programmieren kann. Genau das sollte der Normalzustand sein. Ich sehe nucht was daran neu oder diskussionsbedürftig wäre.

Hier möchte ich genauer auf das MVVM-Pattern eingehen. Das ViewModel ist das Herzstück, was zwischen Model und View steht und die Daten aufbereitet. Man ist also zwingend an das Konzept von WPF bzw. der View gebunden. Man könnte es jetzt so implementieren, dass die View sich das von mir beschriebene Konzept(s. oben) aufgebaut. Da ist ein grober Denkfehler drin. Nicht das ViewModel stellt die Funktionalität bereit sondern die Models. Die ViewModel dienen nur zur Adaption an WPF. Die Models kann man in verschiedensten Anwendungen benutzen und da hat man dann wieder die ganz normale Trennung von Präsentation (View + ViewModel) und Funktionalität (Model).

Baka wa shinanakya naoranai.

Mein XING Profil.

D
69 Beiträge seit 2008
vor 13 Jahren

Natürlich ist abstraktion wichtig - das problem bei abstraction ist nur das es länger dauert ein programm zu schreiben dass in mehrere Layer aufgeteilt ist, und man sollte immer abwägen inwieweit man hier abstrahieren sollten. Ich glaube nämlich die wenigsten hier werden bei jedem kleinen Consolen Tool mit einem eigenen Presentation Layer ausstatten.

Und sollte man wirklich jede kleine Applikation in

Data Access Layer (ADO.NET, Entitiy Framwork)
Network Layer (WCF, TcpIp etc.)
Business Layer (Eine Client bzw Server API die Data Access und Network Layer unter sich vereint)
Presentation Layer (WPF, Silverlight, WinForms, ASP.NET, Console)
und diesen wieder per MVVM, MVC und anderen patterns aufsplitten?

aufteilen? Meist wird das ja nur in den großen Kern Komponenten getan, bei den kleineren Tools ist das ja meist alles vermischt.

Bei Risiken oder Nebenwirkungen fressen sie die Packungsbeilage oder schlagen sie ihren Arzt mit ihrem Apoteker.

F
10.010 Beiträge seit 2004
vor 13 Jahren

@Talla:

Nicht das ViewModel stellt die Funktionalität bereit sondern die Models.

ViewModel == Presenter + Bindbare Properties des Models/ der Modelle.

Das ViewModel ist der Dreh- und Angelpunkt bei der Verarbeitung des UseCase.
Es stellt den Zugriff, aber auch die Businesslogik bereit, die für den UseCase benötigt wird.
Das Model kann auch Businesslogik enthalten, muss aber nicht (POCO).
Auch kann ein VM den Zugriff auf mehr als ein Model realisieren ( z.b. Person/Adresse ).

S
902 Beiträge seit 2007
vor 13 Jahren

Hallo,

auch wenn es schon etwas älter ist, aber...

Business Layer (Eine Client bzw Server API die Data Access und Network Layer unter sich vereint)

... finde ich nicht so gut, denn die BusinessLayer sollte doch von Netzwerktechnik garnix wissen! Nur für leute die hier lesen.

Die Networklayer sollte wenn, dann über der BusinessLayer liegen.

mfg
serial