Suchergebnisse

Hallo Akanel Zitat von Akanel: „Das ist, wenn ich es richtig verstanden habe, eine 1:n Beziehung.“ Sehe ich auch so. Hast du aber im Model nicht. Zitat von Akanel: „Es geht darum das ein Vertriebsmitarbeiter einer anderen Firma Pläne in einem Portal bereitstellt.“ Wie passiert das? Habt ihr da eine Web API? Dann sollte es ja ein Model geben oder? OK, falls nicht: VB.NET-Quellcode (10 Zeilen) PS: Wenn es reine Model-Klassen sind/bleiben kannst du dir die PRoperties mit Backingfield sparen, werden…

Hallo Naja, ich denke das du zu kompiziert denkst, das ist es nämlich gar nicht. Du hast ja gesagt. "Es gibt Vertriebsmitarbeiter und jeder soll x Pläne haben." also hat der Vetriebsmitarbeiter eine Liste von Plänen. = List(Of Plan) Grüße Sascha

Müssen sie nicht. Wie speicherst du denn?? Sowohl mit EF als auch beim Serialisieren ist dies nicht notwendig. In der List Of ist alles drinnen. Eine Liste von Plan. Und Plan hat ne ID in Form einer Guid welche sie von der Basisklasse erbt. Also alles gut. Wie willst du denn speichern bzw. auch wo?

Zitat von Akanel: „Mit dem Komplizierten denken liegt vielleicht daran das ich ein ziemlich kritischer Mensch bin der allen Scheiss hinterfragt wenn ich es nicht gleich verstehe.“ Ist ja auch gut so. Besser einmahl mehr hinterfrage als dann später dastehen wie du Kuh vorm neuen Tor. Am besten du Serialisierst das mal und siehst dir das ergebnis an. Du wirst sehen das die Pläne dem Mitarbeiter zugeordnet sind. Grüße Sascha

Zitat von Akanel: „Wenn ich nun aber mehrere Tabellen habe wo auch m:n beziehungen vorkommen geht das mit OOP nicht mehr. Dazu muss ich dann ein relationales Datenmodell nutzen (in WPF). Hier kann ich dann allerdings nicht mehr einfach in XML serialisieren und müsste EF CodeFirst nutzen.“ Im Grunde schon, ist aber ne frickelei finde ich. Aber EF kann ja nicht schaden die Grundkenntnisse zu lernen. Ist ein super Werkzeug und geht verdamm schnell aufzusetzen. Grüße Sascha

Hallo Zitat von Akanel: „Irgendwie muss doch der Plan "wissen" zu welchem Vertriebler er gehört.“ Naja, jetzt kommt es dann langsam darauf an WIE du später speichern willst. Ich kann EF Core nur empfehlen, aber auch XML ist kein Thema - nur anders. Wie in den vorherigen Posts schon besprochen gibt es da unterschiede auch vom Model her. Bei EF ist der Vorteil das diese Back-Properties wie z.b. die Pläne eines Vertrieblers autromatisch gesetzt werden. Wenn man das ganze mit Serialisierung über z.b…

Hallo Ne, Denkfehler hast du im Grunde keinen. Das ist schon richtig so. Die View hat mit dem Model nix zu tun. Es ist nur so das du im ViewModel etwas mehr arbeit hast wenn das Model zur Datenhaltungsart passt. Also wenn das Model für EF zugeschnitten ist anstatt auf XML hast du weniger Arbeit dann im ViewModel die Beziehungen herzustellen. OK, mach das und melde ich dich dann eben wieder. Schaffen wir schon. Grüße Sascha

Hallo @Akanel Da ist dir glaube ich was passiert beim hochladen. Es sind keine Model enthalten. Grüße Sascha

Das schaut gut aus. Jetzt gibt es zwei Model-Objekte "SalesStaf" und "Plan". Diese beiden schaun sauber und gut aus. Gut gemacht. Grüße Sascha