DB und DTO trennen macht IMO auf jeden Fall Sinn -- sehe ich ähnlich wie du. Das zu koppeln wäre unsauber und gefährlich.
Ich würde das einfach mal als "muss" festsetzen.
Wenn die Verwendung des EF auch "muss" ist, dann bleibt eh keine Wahl mehr, dann müssen da zwei Klassen programmiert werden.
Sonst, ohne EF, könnte man evtl. stellenweise die Daten direkt aus den Tabellen in die DTOs schaufeln und umgekehrt. (Wobei das vermutlich auch recht schnell unsauber wird, also wird es so oder so nicht ausbleiben dass man für jede DB-Entity eine Klasse bastelt.)
Was die Trennung DTO/UI angeht... pfuh. Weiss nicht. Macht vermutlich auch Sinn. Wobei ich mir auch immer denke "is ja irre, alles 3x machen, das muss ja einfacher gehen".
Ahoi,
ich hab nach einigem googeln und rumprobieren einen Out-Of-Process COM in C# gebastelt. Funktioniert soweit auch alles ganz gut, bis auf das gute alte Problem: deterministische Finalisierung.
Dummerweise weigert sich MS ja hartnäckig eine Möglichkeit für die Weiterleitung des "final release" des CCW zu schaffen.
Ich brauch aber mehr oder weniger deterministische Finalisierung (sprich "bald" reicht, "irgendwann" reicht nicht). Also hab' ich mir dazu ein hübsches Singleton gebaut wo alle COM Objekte registriert werden, und einen Thread der dann hin und wieder mal den CCW Ref-Count dieser Objekte kontrolliert -- und bei Ref-Count 0 Dispose aufruft.
Bei Objekten die vom Client per CoCreateInstance erzeugt werden funktioniert das auch ganz toll - da ist der CCW Ref-Count im Konstruktor bereits > 0.
Dumm ist es nur bei Objekten die ich im Out-Of-Process Server selbst instanziere (ganz normal mit new ), und dann als COM-Interface zurückgebe. Zu dem Zeitpunkt wo der Konstruktor läuft gibt es da natürlich noch keine COM Referenzen, das Ding ist ja erstmal ein ganz normales Objekt.
Wenn jetzt genau zur ungünstigsten Zeit mein "COM Object Disposer" Thread los laufen würde, würde dieser nen CCW Ref-Count von 0 feststellen, und das Objekt disposen.
Als Workaround hab' ich jetzt mal QueueUserAPC verwendet. Statt die selbst erzeugten Objekte direkt in die Liste einzutragen, beantrage ich einen Callback mittels QueueUserAPC (über PInvoke).
Und im Callback wird das Objekt dann eingetragen.
Das scheint auch zu funktionieren - anscheinend wartet der Thread der die COM RPC Aufrufe abarbeitet irgendwo in einem "alertable" Zustand, und das erst ausreichend spät, nachdem das zurückgegebene Interface bereits "gemarshalt" wurde.
(Natürlich ist diese Lösung auch alles andere als optimal, da man immer aufpassen muss dass nach QueueUserAPC kein eigener Code mehr kommt der alertable wartet, aber OK, damit könnte ich leben.)
Nur frage ich mich jetzt... ist das halbwegs sicher?
Bzw. fällt jemandem von euch eine bessere Möglichkeit ein freigegebene COM Objekte "einzuklauben"?
Eine Möglichkeit abzufragen ob der CCW für ein Objekt überhaupt schon erzeugt wurde würde auch reichen -- nur hab ich keine gefunden ( Marshal.GetIUnknownForObject ist einfach kommentarlos erfolgreich, selbst wenn das Objekt noch keinen CCW hat).
folgende Seite b hat mich auch zu diesem Thema ein wenig weiter gebracht. Also von daher Closed
http://stackoverflow.com/questions/8738010/get-linq-subquery-into-a-user-defined-type
Ich glaube nicht dass du das Parent manuell setzen solltest.
Wie wärs wenn du einfach den Button und die PictureBox auf/in das Panel legst ?
Du musst dann nur aufpassen welches du zuerst hinzufügst, je nachdem ist dann der Button im Vordergrund oder die PictureBox
Okey... Ich hab eine - für mein Problem - ETWAS einfachere Variante gefunden. Ich stand glaube einfach so ziemlich auf der Leitung... So sogar, daßa es mir peinlich ist...
Das nächste Mal durchforste ich erst mal mein eigenes Google, auch bekannt als Gehirn.
Danke für eure Hilfe..
berniebutt schrieb:
Ich muss mich konsequenter von alten Gewohnheiten in C oder C++ trennen und darf nichts einfach unbedenklich übernehmen.
So ist es. Es gibt eine Reihe von Dingen, die man in C# besser NICHT mehr macht, wenn man von C++ kommt. Ich habe diesen Lernprozess auch durchmachen müssen
http://msdn.microsoft.com/en-us/magazine/cc301520.aspx
http://msdn.microsoft.com/en-us/library/yyaad03b(v=vs.90).aspx
http://windowsdevcenter.com/pub/a/dotnet/2002/02/11/csharp_traps.html
Besser struct nur für einfache kleine Dinge einsetzen. Will man mehr, fertige Klassen verwenden oder solche selbst entwickeln.
Wie KPC schon sagte, ist das vielleicht wichtigste im Zusammenhang mit structs: Nimm sie nur selten und wenn, dann mach sie immutable. Für deine konkrete Anforderung wäre class besser.
@KPC cooler Nick
Man kann jederzeit einen Event-Handler innerhalb derselben Form-Klasse aufrufen mit Event_Name (sender, e); Die aktuellen Event-Daten werden nur weitergereicht. Macht sogar Sinn, z.B. wenn Hilfen sowohl mit dem HelpButton als auch mit F1 aufgerufen werden sollen.
Tut mir leid ich verstehe nicht wirklich was du da versuchst zu machen.
Du injizierst die C.dll in einen anderen Prozess und versuchst dann auf ihre Funktionen von A.exe (mit Hifle der B.dll) darauf zuzugreifen ? Habe ich das richtig verstanden ?
Außerdem verstehe ich nicht was die DLLMain mit der Injektion zu tun haben sollte, ob du darin Code ausführst oder nicht ändert doch nichts daran ob sie injiziert wurde ?
Gibt es eine Möglichkeit, die Dll Injektion durchzuführen und trotzdem von C# aus Zugriff auf die Funktionen zu haben, während sie im Prozess sind?
AFAIK nein. Ich keine keine Möglichkeit von einem Prozess A auf auf Prozess X zuzugreifen und dessen Funktionen aufzurufen.
Was genau hast du denn bisher schon geschafft und was genau klappt nicht ?
Du übergibst einen UTF-16 String und probierst mit Funktionen, welche für ASCII gemacht wurden, mit dem String zu arbeiten. UTF-16 kann Nullbytes enthalten, daher funktioniert strlen nicht.
Die Frage ist nun, was die unmanaged Funktion erwartet? Also welches Encoding wird dort erwartet? ASCII oder womöglich UTF-8? Oder ein Latin-1/2/3/etc? Dem entsprechend musst du den String vorher enkodieren, bevor du ihn an die Funktion übergibst. Je nach Enkodierung gibt es unterschiedliche Vorgehensweisen.
Grüssli
Dravere schrieb:
Eine Anmeldung bei Code Project schadet zudem sowieso nichts, da es dort immer wieder mal gute Artikel hat.
Das stimmt wohl... Da gibt's immer ein par Nützliche Klassen oder DLLs, mit denen man sich einiges erleichtern kann.
Hallo miteinander,
ich habe einen gridview, in der ich Daten mit einem BindingSource fülle.
Zudem habe ich einen Dialog, mit der ich diese Daten ändern kann.
Wenn ich das Tool starte wird das Gridview mit den Daten angezeigt. Ich öffne den Dialog und ändere den Namen. Nun soll nach dem Speichern bzw. Schließen des Dialoges der Name im GridView aktualisiert werden.
Welche Möglichkeiten habe ich da? Gibt es dafür eine Methode wie Update()?
Vielen Dank!
Liebe Grüße
Sonnenschein5
skluge schrieb:
Ich denke, dass es was damit zu tun hat, dass die unmanaged Funktion mir den managed Heap so manipuliert, dass die CLR bei ihrer Überprüfung einen korrupten Speicher entdeckt und deshalb den Fehler wirft. Kann das sein?
Du kannst keine managed-Objekte nicht zum Ändern an eine unmanaged Umgebung übergeben. Es handelt sich um gänzlich andere Welten.
Hallo Leute,
ich habe eine simple Winform anwendung, und möchte Daten "drucken"! für diesen zweck gibts ja die reports!?
Allerdings komm ich da nich ganz klar!! Ich kann ja eine Report Objekt in VS anlegen, und im viewer dann irgendwelche daten bzw. list elemente anfügen!? aber wie bekomm ich meine daten aus meinem model auf den report!? und wie kann ich dann diese ersteler report rpl datei drucken!?
Ich hab mal bisschen gegooglet, aber ich finde da keine konkreten vorteile.. ohje meine nerven:)
Kennt sich jemand damit aus!?
Grüße
Warum nutzt du zur Serialisierung nicht JSON oder XML? Beim Programmstart deserialisierst du die Datei und hälst die Daten im Arbeitsspeicher, beim Beenden serialisierst du wieder in die XML-Datei. Auch wenn du 100000 Objekte in einer Liste im Arbeitsspeicher hälst, ist die Performance bei heutigen Rechnern kein Problem.
