Nein, nicht machen lassen, natürlich führen und erklären, aber mein erstes Wort ist eben nicht Pattern, sondern MessageBox
CodingStyles sind natürlich wichtig und werden auch nicht ausgelassen.
Natürlich sind erklärungen dabei (Datentypen, welche gibt es, int na dann schreiben wir ein Beispiel, string und noch eines)
Aber ich fange nicht damit an das ValueTypes am Stack und refernces am Heap liegen. Ich schneide die Grundlagen an, dass alles erklärt ist was benötigt wird.
int, double, string, DateTime. Mehr brauche ich für eine Adressverwaltung nicht.

Das für jede .Net Anwendung eine AppDomain angelegt wird braucht er in der ersten Stunde noch nicht wissen.
Wenn er am 2. Tag in der Früh auch noch auf der Matte steht, kann ichs ihm ja erzählen.

ich hab mal an einem Tag einem Werksarbeiter das programmieren "beigebracht"
also er hat an diesem Tag 2 Forms mit Datenbankanbindung und die Datenbank geschrieben. Ich habe mich damals für eine Adressenverwaltung entschieden da dieser jeder kennt und man dann nicht mehr lange das Programm selbst erklären muss. Begonnenhabe ich mich mit der MessageBox, dann habe ich ihm ein Spielchen gegeben, wenn er mit der Maus auf einen Button fährt, soll dieser woanders hin. (von links oben nach rechts oben dann rechts unten dann links unten dann wieder links oben) nur um ihm mal ein Gefühl zu geben (auswirkung des geschriebenen)
Und dann habe ich schon mit der Datenbank angefangen, bis am Abend wusste er wie man eine Verbindung aufbaut und wie man ein SQL-Statement absetzt.
Ich habe mich kaum mit dem Theorie Zeugs aufgehalten es ihm zu erklären, ich habs einfach angewendet um ihm nachher erklärt warum.
So vielleicht eine Hilfestellung für die ersten 3 Stunden. danach sieht mans eh wie es weiter geht

zugegen ich habe nicht gesucht, schande über mich.
jedoch auch beim suchen war dann nicht das richtige ergebniss für mich dabei, meist wurde die Antwort, "danke das wars" gegeben.
Der Link von CodeProject war da noch am brauchbarsten, hat mir aber nur indirekt geholfen.
Der wahre Fehler lag dann doch bei mir, beim initialisieren des AsyncOperation war der SynchronizationContext.Current noch null da die Anwendung zu diesem Zeitpunkt noch nicht wusste dass sie eine GUI-Anwendung ist. Ich habe die Initialisierung dann in den ctor der ersten Form verschoben und ... dann gings.

danke das wars 😉

Grüss Euch,

Ich schreibe gerade ein AsyncLoading von Daten.
Funktioniert auch schon wunderbar nur gelegentlich stirbt er. Nach längerer Fehlersuche habe ich herausgefunden ... blabla, nicht wichtig

Lösung:
System.Windows.Forms.Application.OpenForms[0].Invoke(...)

Problem an der Sache, ich habe in der Assembly wo auch auf einer IBindinglist ein ItemAdded-Event feuern will, keinen Verweis auf System.Windows.Forms!
Und es ist nach längerer Besprechung für Buh entschieden worden dieser Assembly diesen Verweis zu geben.
Es gebe die Klasse AsyncOperationManager die so etwas zu tun können versprechen sollte, aber sie lügt.

Hat jemand eine Ahnung wie ich den GUI Thread bekomme ohne einen Verweis auf System.Windows.Forms?

Ich hab jetzt nicht alles gelesen, aber ich glaube, int.Parse() erwartet einen string, aber ItemArray[0] liefert ein object, d.h. ToString() macht aus dem object einen string und somit hängt es das Parse nicht mehr aus.

Auch wenn, wie in Deinem letzten Post eh ein string drinn steht, dieser string wird als object weiter gegeben.
Weiters würd ich, wenn ich mir sicher bin dass ein string drin steht, nicht .ToString verwenden, sondern einen hardcast (string)bla.ItemArray[0] schreiben.
Wenn der DatenTyp der in ItemArray[0] die ToString methode von System.Object NICHT überschreibt wird diese jene aufgerufen und da kommt ItemArray[0].GetType().Name raus und nicht der Value von ItemArray[0].

soweit mein Wissen, ist aber nicht festgenagelt.

Entspricht die Anforderung nicht dem normalen TryGet-Pattern?

public bool TryGetSchnittpunkt(out Point schnittpunkt)
{
  schnittpunkt = new Point(0, 0);
  // Schnittpunkt berechnen
  // out parameter 'schnittpunkt' neu zuweisen;
  // wenn Schnittpunkt existiert, return true, sonst false
}

Aufruf:

Point schnittpunkt;
if (TryGetSchnittpunkt(out schnittpunkt))
{
  // schnittpunkt sinnvoll befüllt, man kann mit ihm arbeiten
}
else
  // schnittpunkt garnicht ansehen, da was sinnloses drin steht

so wie halt das TryGetValue vom Dictionary<T1, T2>

Ich glaube Distinct ist da Deine Wahl
GroupBy gibts auch, habe ich aber noch nicht geschnallt wie man das verwendet

was aber nicht gleich ist, und das wäre für generische methoden auch wichtig, ist die anzahl der Parameter.

public TResult DoSomeThing1<TResult>(int bla, string fasel)
{
    _inner.Info = OwnInfo;
    IResult result = _inner.DoSomeThing1(bla, fasel);
    if (result.ErrorCode != 0)
        throw ScheissenDreckException("");
   return result.Data as TResult;
}

so würde die generische Methode aussehen, allerdings es bleiben zwei Methoden da die Parameteranzahl nicht stimmt.
Lamda-Expressions könnten hier eine Möglichkeit sein, dass ist aber nicht wirklich eine saubere Lösung.

wenn man von alten Spielen redet, komm ich nicht daran vorbei
das (OpenTTD is an Open Source clone of Transport Tycoon Deluxe) zu erwähnen

ja

  string fileName = Path.GetFileNameWithoutExtension(path);

Meines Erachtens nach ist is und as gleich schnell weil sie im Hintergrund ja das gleiche machen: casten und dann schauen ob das Ergebnis in den gewünschten Typ passen.
bei is kommt ein bool raus (Ja würde rein passen), bei as kommt die Instanze oder null raus (Ja passt rein)
Wie hier schon erwähnt mekert FxCop wenn man is und hard cast verwendet, da ist as zu verwenden.
d.h. wenn man nur nach sieht ob das Ding den Typ hat ist is die Wahl, wenn man mit dem gecasteten objekt auch arbeiten muss ist as vorzuziehen.

Da as bei nicht passen ein null in das Ergebniss schriftelt darf es nicht für ValueTypes verwendet werden (compilefehler) (int, struct und bla)
bei string, welch wunder, geht es aber wieder ... was string jetzt nun wirklich ist werd ich wohl nie erfahren. Ok, ich weis es ist im Hintergrund ein immutable char[] aber das ist ein anderes Thema.

Frage an den Autor:
wie hast Du mit Linq geprüft ob es eine TextBox ist?

eventuell geht auch

string string1 = "huhu";
string string2 = "HUHU";

if (string1.Equals(string2, StringComparison.OrdinalIgnoreCase))
{
}

man kann aber auch methoden serialisieren
nämlich die Func<> und Predicate<>, ich habs mal mit dem NetDataContractSerializer oder XmlSerializer gemacht, da kommt ein Xml raus welche als Grundlage für csc/CodeDom dient und dann beim deserialiseren wieder ne Methode raus kommt.

Herbivore liegt richtig, es wird die mit int aufgerufen, der Begründung von Herbivore ist nichts beizufügen.

Also gleich vorweg, irgendwie siehts aus als reden wir von verschiedenen Dingen und meinen dann doch das gleiche

mit "Was sage ich meinem Mockery" meinte ich, das ich ja GENAU sagen muss was wer wieoft aufruft. und wenn ich nur ein Interface habe und nicht weis welche Klasse dahinter aufgerufen wird, kann ich das dann gleich lassen.
d.h. zum testen muss ich wissen wie die Klasse heist und was sie tut.
Zitat
Auf jeden Fall ist nicht null zu erwarten.
Außerdem sollte vielleicht z.B. keine leere Liste zurückgegeben werden.
Oder der Rückgabewert muss irgend etwas mit einem Parameter zu tun haben.
/Zitat
Geht ja nicht, ich muss ihm ja absolut genau sagen was ich von ihm will, objekt, methode, parameter und Rückgabe wert müssen wie die Faust aufs Auge passen. Sonst kackt sich der Mockery an.

Den Fall den Du hier schilderst, muss ich zugeben hatte ich noch nie, wäre mir allerdings auch so nicht in den Sinn gekommen. Dein Beispiel ist aber einleuchtend, zumindest diesen Code möchte ich auch nicht haben.

Nur einen allgemein gültigen Test kann man hierfür nicht schreiben.
Aufgabe: Teste alle Klassen die dieses Interface implementieren.
Geht ja nicht, alle bekannten Assemblies durchreflecten und nach dem Interface suchen? Finde ich jetzt nicht besonders prickelnd.

Ich sah es eher von der Tester-Seite aus, da muss er dann höllisch aufpassen was er tut. Denn es sollte im Testcode erkenntlich sein, dass diese Testmethode eine Rahmenbedingung des Interfaces abprüft und nicht eine der Klasse. Noch dazu soll genau diese Methode für alle Klassen benützt werden die dieses Interface implementieren, kopieren gilt nicht. Ist bei uns ein Minuspunkt, man bekommt es vom Reviewer zurückgeworfen und den Saurus-Award darf man sich auch abholen.

ja, ich habe mich ein bisschen weit hinausgelegt, aber ich finde meine Aussage wurde nicht widerlegt.
Du hast soweit Recht das ein Interface nicht nur ein Vertrag über das Aussehen ist, sondern auch ein Teil der Ausführung.
Ich habe mir in diesem Zuge von IList die Methode Insert angesehen. Ja, verstehe ich, hat auch definitiv eine gute Begründung, z.b. die IndexOutOfRange Exception.

Aber mit dagegen testen, und das war ja die eigentliche Frage, tue ich mir ein bisschen schwer mit Deiner Aussage.

nehmen wir das Beispiel des IClaimsProvider mit der Methode GetClaimResources.
Ich weis nicht welche Klasse sich dahinter verbirgt.
DomainModelClaimProvider geht zum ConfigStore und holt sich mittels UserConfigStoreAssemblyProviderAggregator der im ctor den dtoAssemblyProvider, domainmodelAssemblyProvider und formsAssemblyProvider bekommen hat alle ihm zugeteilten Assemblies um diese dann mittels Reflection nach allen Klassen einer bestimmten Basisklasse zu durchsuchen und mit denen die ClaimResources zusammenbaut.
es gäbe aber auch noch den AttributeClaimProvider, der holt sich die ClaimResources mehr oder weniger mit System.IO von der Festplatte.
So, was sage ich meinem Mockery (NMock) welche Aufrufe er erwarten soll?
Als Benutzer des Interfaces weis ich ja nicht was sich dahinter abspielt.

Das ist das was ich eigentlich meinte.

Ich werde das Gefühl nicht los, dass Du nicht verstanden hast was Interfaces sind.
Klingt ein bisschen grosskotzig aber ich versuch mich mal mit einer guten Erklärung:
Ein Interface ist ein Vertrag, ein Vertrag über das Aussehen.
Wenn ich in meiner Anwendung ein Plugin-System implementieren will um dritt-Programmierern die Möglichkeit zu bieten mein Programm zu erweitern erstelle ich ein offizielles Plugin-Interface (IPlugin)

public interface IPlugin
{
  MenuItem MenuItem { get; }
  void Load();
  void Show();
  void Unload();
}

Beim starten meines Programms führe ich für jedes Plugin die Methode Load aus, hol mir das MenuItem und hänge es zu meiner Menüleiste.
wenn auf das MenuItem geklickt wird führe ich Show aus und beim schliessen des Programms mach ich Unload.
So, und wer sagt das bei Show ein Form kommen muss? Es gibt eine klar festgelegte Anzahl von Personen die das sagen können: 0
Und genau so sind Interfaces zu betrachten. Was dahinter passiert kann man durch den Namen der Methode nicht sagen.
Ich habe gestern ein Interface programmiert, nennen wir es mal IClaimsProvider
und hat eine Methode GetClaimResources.
Es ist natürlich einleuchtend, dass hier eine IEnumerable<Claim> zurückkommt, aber woher?
...
und erraten, ich denke nicht, Du weist nicht wie die Klasse heist, die das Interface implementiert. Die kommen, entsprechend wie in der app.config definiert beim reflecten von einer oder mehreren Assemblies, oder von der Festplatte aus dem ConfigStore oder was weis ich welche Klassen, welche ebenflass IClaimsProvider implementieren, dem ClaimsProviderAggregator (so heist die Klasse) im Constructor übergeben wurden.
Ist mir aber als Konsument des Interfaces auch ziemlich egal, somit kann ich es aber auch nicht testen und wenn die Spezifikation vorschreibt was ein Interface zu tun hat dann hat der Spec-Schreiber das auch nicht verstanden.
Ein Interface bestimmt das Aussehen, nicht Funktion. Ich lehne mich aus dem Fenster und sage ohne Ausnahme.

Ich hoffe ich habe mich jetzt nicht völlig disqualifiziert, aber wenn ich ein Interface erstelle, sehe ich es genau so.

Fang einfach mal mit einem openbook zum thema ADO.Net an.
(links unter Ressourcen sind ein paar Bücher, sonst ist Google Dein Freund)
einen OR-Mapper halte ich persönlich für den Anfang ein bisschen übers Ziel hinaus geschossen. Wenn Du noch kein "Gefühl" für Datenbank hast ist es eine schwere Einarbeitung in OR-Mapper, denke ich.

aber
OleDbConnection con = new OleDbConnection(connectionString);
ist nicht so schwierig

kleiner Link als Hilfe
connectionStrings

bei den ersten 5 Methoden ist es fast klar, die klingen schon gefährlich
beachte dazu die Hilfe zu Thread.Resume
Bei LoadFrom weist Du nicht welche Assembly Du bekommst, wenn eine mit dem gleichen Namen schon da ist nimmt er die, nicht die die Du willst.
LoadFile lädt keine Referencen, LoadWithPartialName klingt in der Hilfe schon komisch, generell sind die meisten Load... Obsolete markiert.

Fazit:
Funktionieren tun alle, aber sie beherbergen unvorhersehbare Fehler (LoadFrom liefert nicht das was es verspricht) und zeigen dadurch auf, dass sich jemand nicht mächtig viel Gedanken über das gemacht hat, wie er was haben will.

SELECT [VieleVieleWörter] FROM Tabelle WHERE [NochmalVieleWörter]

[VieleVieleWörter] und [NochmalVieleWörter] nehmen in Summe bezug auf über 48 Felder.
so würde ich die Fehlermeldung verstehen.

kann sein dass ich mit meinem Vorschlag ja komplett daneben haue, aber bevor ich 81 Textboxen anlege oder mir 2 Stunden ein Datagrid anschaue bis es grafisch so aussieht wie es soll würd ich ein UserControl nehmen eine public Property vom Type int[,] und die Paint oder OnPaint Methode überschreiben

for (int index = 0; index < 10; index++)
{
  e.Graphics.DrawLine(new Pen(Brushes.Black), index * 20, 0, index * 20, 200);
  e.Graphics.DrawLine(new Pen(Brushes.Black), 0, index * 20 , 200, index * 20);
}    
for (int outerIndex = 0; outerIndex < 9; outerIndex++)
  for (int innnerIndex = 0; innnerIndex < 9; innnerIndex++)
    e.Graphics.DrawString((string)sudokuFeld[outerIndex, innerIndex], this.Font, Brushes.Black, new Point((outerIndex * 20) + 10, (innerIndex * 20) + 10));

ich gehe mal davon aus dass Du dann auch einen Mausklick brauchst, da würd ich dann das MausDown o.ä. Event anzapfen dort ne TextBox erscheinen lassen (Size = 20; 20) und bei Enter den Wert in das Array übernehmen lassen, die TextBox verschwinden lassen und dann wird eh wieder das OnPaint aufgerufen.

Wenn ich das getan habe würde ich F5 drücken und schauen was dabei rauskommt.
ja, diese 10 Minuten würde ich mal investieren.

besten dank, ich hab von meine Icon eine bmp gefunden, auf dieser male ich herum und mache daraus ein Icon

besten dank für den Hinweis, das mit dem bmp hab ich nicht geschnallt

Grüss euch,

ich habe anno dazumal ein kleine Tool geschrieben das als NotifyIcon rechts unten bei der Uhr läuft.
Mit diesem Programm kann ich über das ContextMenü 6 Programme starten und stoppen. Momentan haben wir drei icons die folgendes aussagen : alle stopp, einige laufen, alle laufen.
Aus gegebenen Anlass möchte ich aber anzeigen welche Programme laufen.
Das Icon selbst soll eigentlich auf alle stopp bleiben, nur möchte ich kleine grüne waagrechte Striche draufzeichenen. die Programme sind von der Reihenfolge abhängig (WCF-Services) und somit kann von Haus aus 6 Striche hinmalen, Schwarz für gestoppt, grün für laufen
hab auch das gefunden, zumindest passt es mir am besten, jedoch schaffs ich schon mal nicht aus einem Icon ein Graphics object zu erzeugen, beim google bin ich nicht wirklich weit gekommen, zugegeben, beim Suchen bin ich nicht so der Profi.

Wäre toll wenn mir jemand helfen könnte, wäre echt ein cooles Feature.

hmm, dann hab ich keine Ahnung, aus welchen Gründen auch immer kann ich den Choose Items Dialog nicht anzeigen, da sollte es nämlich ein Add Assembly oder sowas geben, aber ich komm da blöderweise nicht hin.
Irgendwas machst Du falsch, bei mir tauchen meine neu geschriebenen UC ( : System.Windows.Forms.UserControl immer automatisch auf)
aber was bei Dir falsch läuft kann ich von hier nie und nimmer feststellen

sry

VS schliessen und neu starten schon versucht?

wenn ich das richtig verstanden habe übernimmt das die CLR in Verbindung mit JIT-Compiler.
da kann man nicht so viel reingreifen, denke ich.
falls Du den JIT-Compiler übergehen willst, kann man die Assembly vorkompilieren (pre-compile)
falls Du eine Assembly global verfügbar machen willst ist "GAC" das richtige Wort dafür

was tut der classloader?

// Edit:
ich tippe mal ins Blaue, Activator.CreateInstance(...)

dann brauchst Du nur kompilieren, die Klasse selbst (das UserControl) muss public sein und das Projekt (die Assembly) muss in der aktuellen Solution bekannt sein.
Vola, das Ding ist da.
Sonst, immer wieder ein guter Versuch, rechte Maustaste auf die ToolBox (bei mir gibt es ein "Choose Items")

die Lösung ist hier eine zweite exe datei

Hauptanwendung startet.
Hauptanwendung überprüft und ev. aktuallisiert die Updateandwendung
Hauptanwendung hat eine dll deren Aufgabe es ist zu überprüfen ob es eine neue Dateiversion für die Hauptanwendung gibt.
Hauptandwendung startet Updateanwendung mit Parameter der exe der Hauptandwendung.
Hauptanwendung killt sich.
Updateanwendung wartet bis Process der Hauptanwendung verschwunden ist und beginnt mit kopieren.
Nach kopieren der neuen Dateien startet Updateanwendung mittels übergebenen Parameter die Hauptanwendung.
Updateanwendung killt sich.

Hauptanwendung überprüft und ev. aktuallisiert die Updateandwendung
Hauptanwendung hat eine dll deren Aufgabe es ist zu überprüfen ob es eine neue Dateiversion für die Hauptanwendung gibt.
Es gibt keine und Hauptanwendung fährt normal hoch.

Man braucht:
eine Hauptanwendung
eine dll zur überprüfung ob es neue Dateien gibt
eine Updateanwendung die kopiert.

Pech gehabt haben.

ich möchte auch noch anmerken, dass es eventuell Sinn machen könnte "einen" eigenen ExceptionTyp zu schreiben.
"alle" Exceptions die in der dll auftreten in diese eine verpacken und dann diese werfen lassen

catch (Exception ex)
{
  throw new EigeneExcpetion("Fehler beim öffnen der Verbindung", ex);
}

und in der Gui hat man nun die Möglichkeit:

catch (EigeneException eex)
{
  // "bekannter fehler"
}
catch (Exception ex)
{
  // unbekannter fehler
}

der Vorteil ergibt sich aber, glaube ich, erst wenn man mehrere dlls hat die sich gegenseitig aufrufen.
und 2. das "eine" und "alle" vom einleitenden Satz ist generell überdenkungs würdig.

als hinweis am Rande:
aber nichts ändern, irgendwann, denke wenn man direkt im Gui Designer auf speichern drückt wird dieses File (der Content davon) neu erstellt.

ja, Multithreading passt nicht in eine einzelne Klasse
Hab mal eine Asynchrone ComboBox geschrieben, da muss man vorher wissen was man tut, bevor man es tut

Wenn alles läuft, kann ich das hier ja nochmal posten, wenn gewünscht.

ist immer gewünscht

ich sehe mir den Code schon ne Zeitlang an und kann mir nicht helfen der gefällt mir nicht.
am Anfang hat man in der Liste nur Types und nach und nach werden diese Types durch UserControl ersetzt, d.h. von aussen kann man nicht mehr sagen was wo ist und man braucht irgendwo einen intelligenten Code der am Item herumschnüffelt ob es ein Type oder ein UserControl ist und notfalls aus dem Type ein UserControl macht den nach aussen verspricht die Liste rein aus UserControls zu bestehen.

Mir würde da als Lösung eher so ein Provider-Pattern/LazyLoading-Pattern vorschweben.
d.h. in der Liste liegt einen Instanz der BasisKlasse, die ja schon vorhanden zu sein scheint. und sobald man auf die BasisKlasse auf eine Property zugreift wird IN der Basisklasse die entsprechende Instanze besorgt, die dann wirklich benötigt wird

new BasisKlasse(typeof(UserControl1))
wäre die Grundinitialisation eines Items der Liste
und das "Activator.CreateInstance" wäre in der BasisKlasse zu finden.

das new UserControl1() wird wahrscheinlich nicht so den Speicher fressen, da ist eher die Frage was im ctor passiert und welche Controls drauf sind?

/* klar, 10.000 UserControls brauchen Speicher, bei 100 mach ich mir aber noch nicht so Sorgen */

// Edit 2:
Ich werde das nächste Mal versuchen, Deinen Beitrag besser zu lesen

// ungültig
Ich persönlich behaupte: /vermute/
es hat was mit der sogenannten Referenziellen Integrität zu tun.

Du kannst keinen Datensatz aus der Haupttabelle löschen, wenn es min. 1 Kind dazu gibt und die Löschweitergabe nicht ausgewählt ist.

Da bin ich ja sowas von oft rein gerannt, seitdem benutze ich es nicht mehr.

// EDIT:
das ist eine Einstellung in Access

Die Begründung für Th96's Aussage:
wenn man den Aufruf von hohen auf den niedrigen ctor weitergibt (von vielen Parametern auf weniger) hat man folglich in jedem ctor ein bischen Code stehen, anders rum steht alles in einem ctor

public class Test
{
  public Test()
    : base() { }
  
  public Test(string param1)
    : this()
  {
    if (param1 == null)
      throw new Exception();
  }

  public Test(string param1, object param2)
    : this(param1)
  {
    if (param2 == null)
      throw new Exception();
  }
}

oder

public class Test
{
  public Test()
    : this("") { }
  
  public Test(string param1)
    : this(param1, new object()) { }

  public Test(string param1, object param2)
  {
    if (param1 == null || param2 == null)
      throw new Exception();
  }
}

man sieht, "throw new Exception()" ist duplizierte logic, manche sagen auch pfui dazu

@JuyJuka: ja sehe ich eigentlich auch so, nach meinem Verständniss ist die Datenschicht ganz unten und hat nur die Aufgabe DTO zu empfangen und weiter zuleiten.
wenn das BO eine Methode hat, darf, nach meinem Verständnis nach, die Datenschicht nichts davon wissen.

Ja es ist ein Interface, aber das sind ja FZelles hinweise sich was anzusehen. Soweit ich ihn kenne, bekommt man keinen Code von ihm.

// Edit
Aber mir fällt auf das er nur die drei kennt 😁

@Peter wg Find/Any
Find liefert T, FindAll liefert List<T> und Any liefert bool
sind so gesehen "ganz" unterschiedliche Methoden

Ich hab mal für ein POC, mehr ist es nicht geworden, eine Transaction "nach programmiert".
Jede Member die aus der Datenbank kam, bekam ein Attribut welches ich bei BeginnTransaction, sprich beim anzeigen, ausgelesen und abgespeichert habe (Dictionary<string, object>) => (Dictionary<PropertyName, PropertyValue>)
Bei den Listen war es schwieriger, aber ich habe mir eine eigene ableitung von List<T> geschrieben, die ebenfalls eine BeginnTransaction Methode bekam. In dieser hat er sich alle Elemente in einer eigenen Liste "gemerkt" und die Methode an die Kinder (Elemente) weitergeleitet.
Dann hat man nach BeginnTransaction alles im Cache liegen, bei Commit (Abbrechen) schmeisst man den Cache weg und schickt die Person zur Datenbank. Bei den Listen ist es wie gesagt schwieriger, da man die gelöschte Files extra cachen muss um sie danach zu löschen. Bei Rollback übernimmt man die "gemerkten" Werte einfach wieder zurück in die Properties, schmeisst den Cache DANACH weg und nichts ist passiert.

DatenbankTransaction "kann" man benützen, funktioniert auch, und ist wahrscheinlich vom Erfinder auch so gedacht. Aber mir gefällt der Stil ganz einfach nicht.

Du wirst im Object Person eine Listen haben müssen (Files)
diese wird beim anzeigen oder erstellen der Person vollständig aus der Datenbank befüllt.
aus dieser löscht Du den Eintrag raus, merkts Dir aber das gelöschte File,
beim speichern gehst Du damit zur Datenbank und haust das Ding dann wirklich weg
Hoffe habe das verstanden was Du meintest

Ich möchte hier Herbivore ein bisschen Rückendeckung geben. Ich selbst bin leidenschaftlicher Praktiker, also ich tue einfach mal und schaue was da rauskommt ... nicht sehr hilfreich! Man braucht echt die Grundlagen über Theorie UND Praxis! die Praxis bekommt man durchs praktische Arbeiten aber die Grundlagen helfen nur Bücher und Kurse.
Beim Thema theoretische Grundlagen hat mich dieses Buch extrem nach vorne gehaut.

Aber meines Erachtens nach am besten ist:
Man muss nicht alles wissen, aber das was man weis muss sitzen

Habe vor einem Jahr das erste Mal als C# Programmierer einen Job gesucht, bin in drei Wochen 1.500 - 2.000 km für Bewerbungsgespräche gefahren.

Fazit:
Du musst beweglich sein, Dir muss es egal sein wo Du arbeitest, als Anfänger mit einem "niedrigen" Gehalt einverstanden sein und dann bekommst Du zu 100% einen Job.
Ich hatte 3 Zusagen und punkto C# war (bin) ich ja ne Niete.
Unter niedriges Gehalt würde ich einen Bereich von 1.000 bis 1.300€ verstehen*.
Falls es für Dich möglich ist würde ich versuchen in Wien zu landen, hier verdienst Du für die gleiche um ca 500€ mehr*.
Graz ist insofern schlecht(er) da Du meist mit dem Auto zur Arbeit fahren musst und die öffentlichen in Graz sind ... nennen wir es mal verbesserungswürdig. In Wien kommst Du gänzlich ohne Auto aus. Allerdings sind die Lebenserhaltungskosten in Wien höher.

Aber ich denke mir einen Job als Programmierer kann man immer bekommen, hängt halt sehr von Deinen Bewerbungsgesprächen ab. Und dass Du genug davon hast beachte unbedingt die Internet Job-Portale, setzte Dich mit jedem Eintrag auseinander. Es macht keinen guten Eindruck wenn man alle anschreibt! Die sehen dass auf Grund von den Bewerbungsunterlagen wie Du Dich vorbereitet hast und ob Du weist was Du suchst. Denke es ist fast wichtiger sich für den neuen Job zu interessieren, als sich gut auszukennen. Das ist zumindest der Grund warum ich angestellt wurde. Zumindest war es sicher nicht mein Wissen 😉

*Angabe ohne Gewähr, hab ja keine Ahnung wo Du wohnst und wieviel Du kannst.

was heist -> WTF?! <- ?

das ist jetzt nur meine Meinung, aber ich finde es generell schöner und besser bedienbar wenn im Datagrid nicht eine leere Zeile für neue Einträge ist, sondern Add/Edit/Remove Buttons herumschwirren und bei Klick ein Fenster aufgeht, ist zwar bei manchen fast verpöhnt, aber ich mags so.
Wenn Du kein neues Fenster haben willst, dann kannst Du ja die Textboxen wiederverwenden, aber eben halt mit Schaltflächen enablen/disablen

Ich bin Zimmerergeselle (der Typ am Dach mit der Motorsäge und dem grossen Hammer), habe allerdings 7 Jahre Programmiererfahrung und 9 Jahre EDV (2 Jahre PC-Zusammenbauer) und habe bei meinem jetzigen Job so an die 70 Bewerber "ausgeschaltet" und da wahren sicher auch einige dabei die bereits ein fertiges Studium haben. Bin aber "nur" Programmierer, möchte aber auch nichts anderes sein. Die Leute im Management haben mir zuviel Stress.