Bindung nach Entity Model first aktualisiert Daten nicht!

  • WPF

Es gibt 118 Antworten in diesem Thema. Der letzte Beitrag () ist von Jeiss.

    Hallo ErfinderDesRades.
    ​Ja, hab ähnlich wie du eher schlechte Erfahrungen mit ManagementStudio​ gemacht. Hatte auch mal den Fall, dass gar nix mehr ging....
    ​Es hängt natürlich davon ab wie tief du da reingucken willst. Aber ich find der ServerExplorer im VS selber kann da manchmal helfen. Connection zur DB hinzufügen, und da kannste schon mal ein bisschen was sehen. Und Script eingeben geht auch.
    Hallo Sacha,

    Nofear23m schrieb:

    keine Fragen?

    machst wohl Witze?!
    Weiss nicht wo ich anfangen soll.
    Bin total überfordert mit deinem letzten Projekt!
    Aber ich bleibe dran....
    Zu viele neue Elemente drin für mich, und das alles gleichzeitig...

    Ich übe wieder fast täglich WPF.
    Und wenn ich dann mal soweit bin, werde ich wahrscheinlich versuchen ein neues Projekt anzulegen. Und dann nach und nach "deine" Elemente da reinbauen.
    Vielleicht erkenn ich dann besser wie alles funktioniert wenn nicht alles gleichzeitig passiert...
    Melde mich hoffentlich bald zurück.
    Aber danke der Nachfrage.

    Nofear23m schrieb:

    @ErfinderDesRades, deine Meinung?!
    Zu was - zum SqlServer-Problem?
    Findich sch...

    oder meinst du zu deine MVVM-Solution?
    Findich gut :thumbsup:
    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 :thumbup:

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    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
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nofear23m“ ()

    Hallo Sascha,
    das mit deinem Namen, das tut mir leid. Und obendrein komm ich mir auch noch blöd vor...
    Hab einfach nicht richtig hingekuckt. Hatte bis jetzt keine Ahnung, dass es für deinen Vornamen verschiedene Schreibweisen gibt.

    Bein uns hie in Luxemburg gibt es einen sehr grossen französischen Einfluss in unserer eigenen Sprache. Und bei uns wird Sascha eben "auf französisch" geschrieben, was Sacha ergibt! (wird aber auch "sch" ausgesprochen). Wie z.B. "acheter" ( Verb "kaufen" - Lies: ascheter) oder "marcher" (Verb "laufen" - lies: marscher)
    Also nicht die geringste schlechte Absicht, kann ich dir versichern.
    So dann wär das ja jetzt geklärt.

    Die Frage mit dem Codebehind vom Mainwindow. da hab ich das hier gemeint.

    VB.NET-Quellcode

    1. Class MainWindow
    2. Private Sub MainWindow_Loaded(sender As Object, e As RoutedEventArgs) Handles Me.Loaded
    3. Using db As New OrdersContext.OrdersDbContext
    4. db.Database.CreateIfNotExists()
    5. If db.WorkCenters.Any Then
    6. End If
    7. End Using
    8. End Sub
    9. End Class

    Wird ja schon "früher" im Code behandelt. Und zwar an dieser Stelle.

    VB.NET-Quellcode

    1. Namespace Workspaces
    2. Public Class MainWorkspaceVm
    3. Inherits ViewModelBase
    4. Public Sub New()
    5. If Not IsInDesignMode Then
    6. 'DB initialisieren und wenn nötig Default-Daten schreiben
    7. Using db As New OrdersContext.OrdersDbContext
    8. db.Database.CreateIfNotExists()
    9. If Not db.Orders.Any Then
    10. db.WorkCenters.Add(New WorkCenter("WorkCenter 1", 5))
    11. db.WorkCenters.Add(New WorkCenter("WorkCenter 2", 10))
    12. db.WorkCenters.Add(New WorkCenter("WorkCenter 3", 12))
    13. db.WorkCenters.Add(New WorkCenter("WorkCenter 4", 3))
    14. db.SaveChanges()
    15. Dim answere As New Answer() With {.AnswerText = "Antworttext", .ContactName = "Neue Kontakt", .RequestDate = DateTime.Now}
    16. Dim answereList As New List(Of Answer) : answereList.Add(answere)
    17. db.Orders.Add(New Order() With {.ConfirmationDate = DateTime.Now, .ArticleNr = 12345, .Description = "Testartikel", .Remarks = "Beschreibung" _
    18. , .Answers = answereList, .OrderNr = 521145, .Quantity = 235, .CurrentWorkCenter = db.WorkCenters.First})
    19. db.SaveChanges()
    20. End If
    21. End Using
    22. End If
    23. StatusBarVm = New StatusVm
    24. OrdersVm = New UrgencyListVm(StatusBarVm)
    25. End Sub

    ​Wird dieser "Codebehind" im Mainwindow doch gebraucht? Würde mich doch irgendwie "verwirren" (lies: würde ich nicht verstehen) wenn der nötig wäre.

    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
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Ok, dann mal nichts wie weg mit dem Codebehind.
    ​Es werden bestimmt noch viele Fragen folgen. Aber ich versuch mal ne kleine Weile allein zurecht zu kommen. Das zwingt mich über vieles nachzudenken und natürlich auch vieles nachzuschlagen... Und dabei lerne ich dann immer irgendetwas dazu. Was in meinem Fall wirklich nötig ist...
    Hallo Sascha,
    Komm in deinem tollen Demonstrations-Projekt nicht weiter. Brauch neue "inputs" von aussen...
    Kanns du (oder sonst wer der's kann) mir die Drei ersten Zeilen welche durchlaufen werden erklären ?(
    Ich drücke F10 im Projekt, und schon gleich hier

    VB.NET-Quellcode

    1. Private Sub Application_Startup(sender As Object, e As StartupEventArgs) Handles Me.Startup
    2. ServiceInjector.InjectServices()
    3. End Sub
    ist es schon vorbei!
    Wieso sehe ich die Klasse ServiceInjector nicht im Solution explorer? Ok ist NotInheritable, gut das geht noch...
    Warum im "Ordner" UrgencyPlanner.App, hat das eine besondere Bedeutung? Automatisch so angelegt worden oder aus freiem Wille?
    Ok, stellt die "Funktionalitäten" für Messageboxen, Windows Dialoge und Waiting cursor bereit. Leuchtet mir ein, dass wir das im MVVM irgendwo "herholen" müssen.
    Hab auch meine Mühe den Aufruf

    VB.NET-Quellcode

    1. Public Shared ReadOnly Instance As New ServiceContainer()
    in der Klasse ServiceContainer selbst zu verstehen...
    Also eine kleine "Gebrauchsanweisung" könnte mir jetzt vielleicht noch helfen über meinen "Frust" hinweg zu kommen.
    Diese Instanzen von ServiceContainer bleiben ja bestimmt während der ganzen Laufzeit der App erhalten, oder welche "Lebenserwartung" haben die?

    EDIT:
    Ooopppss!
    Hab die Augen geöffnet, und siehe da, die Klasse ServiceInjector ist doch auf einmal im Solution explorer zu sehen! Sorry

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Jeiss“ ()

    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
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo Sascha,
    ​Ich weiss es sehr zu schätzen, dass du immer so hilfsbereit bist. Freut mich richtig.
    Wenn es aber zu kompliziert wird (einem Anfänger wie mir das verständlich zu machen), dann "reicht" es mir auch schon wenn du mir die Vorgänge erst mal erklärst/beschreibst.
    Denn irgendwie sind das doch sehr eigenständige "Instanzen" welche die übrigen Funktionen der App nicht richtig beeinflussen. Die ViewModels aus den Workspaces führen ja irgendwie "ihr eigenes Leben".
    ​Wenn später dann einmal, nach weiteren Fragen/Antworten, mein Wissenstand etwas gestiegen ist, werd ich das alles ja hoffentlich etwas besser verstehen.
    ​Für mich sind diese "Services" irgendwie zu "abstrakt", ich kann sie nicht verfolgen, wie ich es z.B. mit dem Wert einer Property verfolgen kann (im Debug modus)
    ​Wenn du mir bestätigen könntest, dass ich mir die jetzt am Anfang noch "wegdenken" darf. Dann ist es für mich ok wenn wir später einmal darüber sprechen.
    ​Es irritiert halt aber wenn man ein Projekt genauer verstehen will und man scheitert bereits bei der ersten Anweisung....
    ​Darum, wenn du mir mal "einfacherzählen" könntest was da so vor sich geht. Und vor allem falls in den paar Zeilen doch was passiert was halt eben wichtig ist für das Verständnis der Ereignisse im späteren Verlauf...
    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)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    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
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    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?
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Namespace Services
    2. Public Class ServiceContainer
    3. Public Shared ReadOnly Instance As New ServiceContainer()
    4. Private Sub New()
    5. ServiceMap = New Dictionary(Of Type, Object)()
    6. ServiceMapLock = New Object()
    7. End Sub
    8. Public Shared Sub AddService(Of TServiceContract As Class)(implementation As TServiceContract)
    9. SyncLock ServiceMapLock
    10. ServiceMap(GetType(TServiceContract)) = implementation
    11. End SyncLock
    12. End Sub
    13. Public Shared Function GetService(Of TServiceContract As Class)() As TServiceContract
    14. Dim service As Object = Nothing
    15. SyncLock ServiceMapLock
    16. ServiceMap.TryGetValue(GetType(TServiceContract), service)
    17. End SyncLock
    18. Return TryCast(service, TServiceContract)
    19. End Function
    20. Private Shared ServiceMap As Dictionary(Of Type, Object)
    21. Private Shared ServiceMapLock As Object
    22. End Class
    23. End Namespace


    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Nofear23m“ ()

    Der Singleton ist ja schnell nachgebessert:

    VB.NET-Quellcode

    1. Public Class ServiceContainer
    2. Public Shared ReadOnly Instance As New ServiceContainer()
    3. Private Sub New()
    4. End Sub


    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

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    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 :cursing:
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    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.