Bindung nach Entity Model first aktualisiert Daten nicht!

Hallo

@Jeiss, keine Fragen?
@ErfinderDesRades, deine Meinung?!

Grüße
Sascha

Nofear23m schrieb:

@ErfinderDesRades, deine Meinung?!

Zu was - zum SqlServer-Problem?
Findich sch...

oder meinst du zu deine MVVM-Solution?
Findich gut
Wie gesagt, ist für mich total nervig (s.o.), dass ich kein ER-Model der Datenbank kriege, die da generiert wird.
Ich möchte sehen, ob da eine korrekte 1:n-Relation generiert wird, mit Löschweitergabe.

---

Als nächstes würde ich sehen wollen, wie man eine M:1:N - Relation arbeitsfähig realisiert.
Bei mir selbst hab ich eine aufgesetzt, am Beispiel einer Bestellung-UI - ModelFirst.
Aber das wäre hier offtopic - sollte man vlt. im Sourcecode-Austausch einen Thread zu eröffnen - haste Lust?

Ist ich finde sehr interessant, ich hab die letzte Woche voll in T4-Templates rumgewütet, und bin da jetzt Profi.
Und dank meiner Templates (und noch viiieel mehr Infrastruktur) kann ich die gesamte Bestellung-Anwendung mit < 100 Zeilen VB-Code abhandeln.
Es entspricht sicher nicht deinen Vorstellungen von MVVM - aber wenn ich diesen entsprechen wollte, würde ich wieder versuchen, wieviel davon ich mit T4 abhandeln kann - T4 kann ja nicht nur Models generieren, sondern auch Viewmodels.

guck den Code an, da sollte man eiglich drauf kommen, was der macht.
Oder poste ihn einfach - ist ja nicht viel.

hmm - eiglich haste recht. Was da sinnvolles getan wird, wird ja an viel geeigneteren Orten ebenfalls getan - daher sollte das an der Stelle komplett weg - denke ich, mittlerweile.
Und nehme an, das ist auch der Hintergrund deiner Frage

Jeiss schrieb:

Hi Sacha,

Muss ich jetzt mal schreiben, ich verabschiede mich stets mit "Grüße Sascha", und du nennst mich IMMER Sacha. Why?

Jeiss schrieb:

Codebehind im Load-event des Mainwindows, ist der einfach "so da liegen geblieben"?

Habe im CodeBehind des MainWindow KEINEN code. Lediglich im ModalDialogWindow, damit sich dieses mit ESC schliessen lässt und das ist legitim.

ErfinderDesRades schrieb:

Was da sinnvolles getan wird, wird ja an viel geeigneteren Orten ebenfalls getan - daher sollte das an der Stelle komplett weg - denke ich

Von welcher Codestelle sprichst du?

EDIT:
@ErfinderDesRades

Wie gesagt, ist für mich total nervig (s.o.), dass ich kein ER-Model der Datenbank kriege, die da generiert wird.

Lade dir das VS AddOn EF PowerTools runter. Damit habe ich auch das Diagramm erstellt.
Aber.... Löschweitergabe habe ich keine erstellt, bei mir kannst du nicht löschen!! Man soll in einer DB nix löschen können!!!!
Bevor wir jetzt Diskutieren werde ich konkreter. Der Enduser soll in einer DB nix löschen können, der Admin macht es sowieso nicht über die App.

Als nächstes würde ich sehen wollen, wie man eine M:1:N - Relation arbeitsfähig realisiert.

Einfach bei CodeFirst
Aber: Egal ob CodeFirst, ModelFirst oder DatabaseFirst HIER sind alle Infos

Aber das wäre hier offtopic - sollte man vlt. im Sourcecode-Austausch einen Thread zu eröffnen - haste Lust?

Gerne. Da hätte ich sogar ne Idee. Wir könnten hier gleich CodeFirst mit ModelFirst gegenüberstellen.
Also z.b. eine M:N beziehung und wie man diese hier und wie man sie dort macht. Und die vor und nachteile.

Grüße
Sascha

Jeiss schrieb:

Und obendrein komm ich mir auch noch blöd vor...

Musst du nicht. Kein Thema, wollte es nur klarstellen. Das mit dem Frazösich wusste ich gar nicht. Es gibt z.b. auch Sasa im Jugoslavischen was auch gleich gesprochen wird. Deshalb bin ich da heikel *gg*

Jeiss schrieb:

​Wird dieser "Codebehind" im Mainwindow doch gebraucht?

Sorry für die verwirrung, ist in meinem Projekt nicht vorhanden, anscheinend habe ich da die ZIP ein wenig zu früh erstellt und danach wohl noch ein wenig bereinigt.
Kann natürlich weg!!

Habe das Projekt gerade nochmals durchgesehen, der rest sollte passen.
Sorry für den kleinen Fehler. Hast du aber SEHR gut erkannt. Tadellos. Das zeigt mir das du wirklich versucht den Code und das Projekt als ganzes zu verstehen, was mich freut. Das lobe ich mir.

Sonst noch fragen?? Frag ruig!

Grüße
Sascha

Hallo

OK, ich dachte mir das du hier die ersten Fragen stellen wirst.
Ich bin nur am Überlegen wie ich das am besten, so das du nachher nicht noch verwirrter bist als jetzt, erkläre.

Ich überleg mir was und Antworte dir dann morgen, mal sehen wie ich das einfach rüber bring.

Grüße
Sascha

Hofflich ärger ich NoFear nicht, wenn ich einfach mal zu erklären versuche - soo schwierig findich das ja garnet:

Jeiss schrieb:

VB.NET-Quellcode

1. Private Sub Application_Startup(sender As Object, e As StartupEventArgs) Handles Me.Startup
2. ServiceInjector.InjectServices()
3. End Sub

... Ok, stellt die "Funktionalitäten" für Messageboxen, Windows Dialoge und Waiting cursor bereit...

Ach guck - weisst es ja eiglich schon.
Eben - Application_Startup() ist quasi der Einsprungspunkt der Anwendung, und ServiceInjector.InjectServices() ist also das allererste, was ausgeführt wird.

Jeiss schrieb:

VB.NET-Quellcode

1. Public Class ServiceContainer
2. Public Shared ReadOnly Instance As New ServiceContainer()

Instance ist nicht mehr und nicht weniger als eine globale Variable.
In der gesamten Anwendung, über die gesamte Laufzeit, soll dieses eine Objekt - ServiceContainer.Instance As ServiceContainer unveränderlich abrufbar sein.

(Hihi - tatsächlich hab ich dir jetzt nur den Code nochmal vorgelesen.
Application_Startup - zu deutsch: das allererste
Public Shared Readonly Instance - deutsch: global abrufbar, unveränderlich)

Also, es ist jetzt für das verständniss vom MVVM nicht sooo wichtig das du verstehst wie das mit dem Service funzt. Es ist, wie soll ich sagen, eine "feinheit" die man in MVVM macht um wirklich nicht gegen das Pattern zu verstoßen.
Es ist jetzt auch gar nicht so wichtig am Anfang zu verstehen was welche Zeile ganz genau macht. Wichtig ist mal zu verstehen was in etwa da jetzt passiert, das reicht erstmal.

Ich versuchs mal:

Alles was irgendwie mit View und Userinteraction zu tun hat, hat in einem "echten" MVVM nichts zu suchen. Da kommt es eben immer darauf an wie weit man das treiben will und in wie weit man sich an das Pattern halten möchte.
Wir gehen jetzt mal davon auch das wir uns an das Pattern halten wollen. Warum soll mann die Messagebox nicht im ViewModel aufrufen können? Tja, wenn ich ein korrketes ViewModel habe kann ich dieses genauso für eine HandyApp oder etwas anderes verwenden. Doch dort gibt es keine Messagebox. Aber es gibt ein DialogMessage. OK, dann muss ich aber zwei ViewModels schreiben. Ne, das will ich ja nicht.
Also mache ich einen Bauplan (Interface) wie z.b. das IMessageboxService. Dieser Bauplan sagt, ein Messageboxservie muss die Methode Show haben welche ich ein paar Parameter mitgeben kann.
Weil das ist es eben was eine Messagebox auch in wirklichkeit benötigt. OK, soweit gut. Ich habe einen Plan für eine Messagebox.

Jetzt kann der Bauplan genommen werden um in die Tat umgesetzt zu werden.
Unsere App ist eine Windows-Desktop App, sie verwendet eine Messagbox um eine Meldung anzuzeigen. Gut, die App hat also eine Klasse. MessageboxService. könnte aber natürlich auch völlig anders heissen.
diese Klasse soll sich darum kümmern den Bauplan IMEssageboxService in die Tat umzusetzen. Also implementiert sie IMessageboxService. mit Implements IMessageboxService.

Dadurch wird automatisch von VS die Methode Show (besagt ja der Bauplan) generiert. Innerhalb dieser Methode schreiben wir Code der ausgeführt werden soll wenn eine Messagebox gezeigt werden soll.
OK, hier habe ich ein paar Zeilem mehr drinnen welche jetzt nicht so relevant sind. Im Grund reicht ein "Return Messagebox.Show(.......)".

Hätten wir nun noch eine UWP App würde diese auch eine Klasse haben welche IMessageboxService implementiert nur würde diese dann in der Methode Show etwas anderes ausführen um eben keine Messagebox zu zeigen (weil die gibt es ja nicht unter UWP) sondern ein DialogMessage.

Weiter:
Der ServiceContainer (im ViewModel-Projekt) dienst als Container für diese Services. Diese Klasse ist als SingletonClass erstellt. Sprich, die Klasse kann nur einmal instanziert werden und es wird IMMER DIE SELBE Instanz zurück gegeben, auch über mehrere Assemblys hinweg. Man muss kein Dim xy As New ServiceContainer schreiben. Sondern einfach nur ServiceContainer.BlaBla.
Über diese kann ich ein Service zum Container hinzufügen und abrufen. Gebe ich vorher ein IMessageboxService in den Container bekomme ich später mit GetService diese Service wieder.

Und genau dafür sorgt ServiceInjector.InjectServices() im Application_Startup. Er ruft eine Prozedur auf welche mit ServiceContainer.Instance.AddService(Of IMessageboxService)(New MessageboxService()) dafür sorgt das im Falle das das ViewModel mit dieser Desktop-App verwendet wird (und das tut es ja weil ja die App die Prozedur aufruft), die MessageboxService Klasse in dern Container kommt weil die App mit dieser Arbeiten möchte damit eine normale Messagebox geöffnet wird.

Ich kann sowas nicht so gut erklären, vieleicht kann @ErfinderDesRades das ja besser, ich finde das er besser erklären kann als ich.
Aber wenn du fragen hast kann ich es auch gerne nochmals versuchen.

EDIT: Ups, hat ers dazwischen sogar versucht.

Grüße
Sascha

Nofear23m schrieb:

Der ServiceContainer [...] ist als SingletonClass erstellt. Sprich, die Klasse kann nur einmal instanziert werden

Das stimmt leider nicht.
Die Klasse ServiceContainer ist kein Singleton, ist also durchaus instanzierbar, sooft und wo man will.
Es ist nur sehr geraten dieses zu unterlassen, und stattdessen die eine Instanz: Instance zu nehmen.

ErfinderDesRades schrieb:

Das stimmt leider nicht.
Die Klasse ServiceContainer ist kein Singleton

Stimmt (!!), danke für den Hinweis. Mein Fehler, dachte ich hatte die als Singleton erstellt, habe ich aber nicht. Warum eigendlich nicht? Mmmmhhhhh.
Muss ich mir nochmal ansehen, die Funktion ist die selbe, aber wie @ErfinderDesRades schrieb, immer die "Instance" verwenden.
Danke für den Hinweis.

EDIT:
@ErfinderDesRades, was haltest du davon? Eleganter oder?


Grüße
Sascha

Der Singleton ist ja schnell nachgebessert:

Aber nochmal zu dem Injector-Pattern - heisst das so?
Das ist also offensichtlich nicht unmittelbar verstehbar, und ich hab den Sinn auch nicht verstanden gehabt, bis du erklärst, dass du damit vorbereitest, auch eine UWP-App zu schreiben (was immer das sein mag), die dasselbe Viewmodel-Projekt benutzt.
Ist halt recht verwirrend: Man findet Service-Klassen im App-Projekt, Service-Interfaces im Viewmodel-Projekt, und da findet man auch den ServiceContainer, aber den ServiceInjector, der ist wieder inne App, tut aber nix anneres, als den ServiceContainer im Viewmodel aufzurufen.
Also das kommt einem schon wie eine sehr eigentümliche gegenseitige Abhängigkeit und wie Pingpong-Spielen vor.
Aber jetzt verstehen wirs: Es ist, damit man das Viewmodel auch für UWP-Apps wiederverwenden kann.
Woran von uns allerdings keiner im Traum jemals gedacht hätte, und was auch ganz sicher niemals passieren wird.
Und wenn es - theoretisch! - doch passieren sollte - also ich kenne mich mit den Bedingtkeiten von UWP-Apps nicht aus - aber ich könnte mir vorstellen - äh - geht garnet .
Möglicherweise ist dieses Viewmodel für eine UWP-Apps so garnet verwendbar - und dann?
Dann haste hier was ziemlich verwirrendes konstruiert, auf dessen Sinn Jeiss und ich von selbst nicht kommen konnten, und was nur unsere Stirn sich kräuseln lässt.
Und am Ende möglicherweise auch noch garnet aufgeht.
Diese meine defätistische Denkweise ist übrigens nicht (nur) meine private Persönlichkeits-Störung, sondern es gibt ziemlich rennomierte Architektur-Theoretiker (etwa die Clean-Code-Developer), die diese Denke als "YAGNI" - Prinzip formuliert haben.
de.wikipedia.org/wiki/YAGNI
Google liefert aber auch viele andere Treffer auf den Begriff hin.
Guck - hier äussert sich sogar Martin Fowler erselbst (gilt als Erfinder von MVVM) dazu: YAGNI

ErfinderDesRades schrieb:

Aber nochmal zu dem Injector-Pattern - heisst das so?

Im Grunde ist es ja DependencyInjection

ErfinderDesRades schrieb:

auch eine UWP-App zu schreiben (was immer das sein mag)

Ein UniversalWindowsPlatform-App (Windows 8 App, Windows 10 App Windows Phone App, Windows 10 Core App in einem)

ErfinderDesRades schrieb:

Woran von uns allerdings keiner im Traum jemals gedacht hätte, und was auch ganz sicher niemals passieren wird.
Und wenn es - theoretisch! - doch passieren sollte - also ich kenne mich mit den Bedingtkeiten von UWP-Apps nicht aus - aber ich könnte mir vorstellen - äh - geht garnet .
Möglicherweise ist dieses Viewmodel für eine UWP-Apps so garnet verwendbar - und dann?
Dann haste hier was ziemlich verwirrendes konstruiert, auf dessen Sinn Jeiss und ich von selbst nicht kommen konnten, und was nur unsere Stirn sich kräuseln lässt.

Da ist/war ein Beispiel. Egal ob Xamarin, MVC Website oder was anderes. Solch ein ViewModel ist für dies alles wiederverwendbar.

Nochmal @ErfinderDesRades, es sagt keiner das du MVVM machen musst, es zwingt niemand irgendwem oder? Aber WENN du MVVM machst, dann sollten die 3 Layer (Model-View-ViewModel) aber auch getrennt werden, und das geht nur mit DependencyInjection. Langsam (nach mittlerweile Monaten) geht mir die Diskussion warum und weshalb echt ein wenig auf den Nerv. Du kannst noch so viele Argumente bringen welche DEINER Meinung nach vieleicht gut und noch soviel dagegen sagen. MVVM ist und bleibt MVVM, und wenn du es noch so viel abändern willst. Das Pattern gibt eine gewisse herangehensweise vor, lässt man einen Teil des Rezeptes weg ist ist es kein MVVM mehr sondern z.b. MVP oder MVC oder, oder, oder.
In unserer ersten Diskussion warst du noch der Meinung das du im ViewModel ein Fenster aufmachen und darin den DatenContext setzen kannst wie es auch im Tut ist, wo du dann ja eh eingelenkt hat, ich will das aber nicht jedes mal neu durchkauen. Die Layer sind zu trennen, anderenfalls ist es kein MVVM, und wir reden hier doch von MVVM, sicher gibt es einfacheres und auch sicher sinnvolleres, MVVM ist doch nicht das allerheiligste und allerbeste und allertollste und sicher nicht das allerleichterste.
Und eines muss klar sein, sobald wie von MVVM reden, reden wir über große Anwendungen welche auch ein gewisses Maß an Logik und komplexität beinhalten, denn eines sein doch mal ganz ganz deutlich gesagt, für kleine Anwendungen und gewisse Anwendungen ist MVVM völliger Mist!!! Ich setze doch kein MVVM auf wegen 5 Views welche meine Anwendung haben wird.

Beispiel: Arbeite an etwas wo ein Webservice Daten über EntityFramework von einer DB bezieht. Eine Win Applikation sowie eine MVC Website und später eine Xamarin App sollten die Daten über das Webservice beziehen und speichern können. Evtl. müssen ein Teil der Funktionen später mit einer UWP App auf einem Rapsberry PI mit Win IOT Core laufen.
Ich schreibe sicher nur einmal des ViewModel, bin ja nicht doof.

Also, genre können wir über das Projekt und natrülich auch gerne über vor und nachteile von Codeteilen und auch vor und nachteile von MVVM. Aber Aussagen wie oben das es quatsch ist nur weil einer Person nicht in den Kram passen will das es heute weit mehr gibt als Windows und es auch mehr herangehensweisen gibt als auf den ersten Blick vieleicht erkannbar werde ich versuchen nciht mehr zu kommentieren, das hatten wir bereits zu oft. Manchesmal muss man auch etwas über den Tellerrand sehen. Willkommen in 2018 !!!

Grüße

Jo - meine Denke mag unbequem sein.
Aber - ähm - zu MVVM habich mich doch grad garnet geäussert? Was (ich darf sagen: "unsere") Verständnis-Probleme verursachte war doch die Dependency-Injection - oder gehört die in deim Verständnis nu auch mit hinein in den MVVM-Pattern?
Aber ich bin jetzt still - sonst verlierst du am Ende noch die Lust an diesem Thread - das ginge unfairerweise zu Lasten von @Jeiss. Ich weiss auch garnet, ob ich bewirke, was ich bezwecke: Nämlich eine kritische Distanz zu erhalten.