für den Datenbankzugriff verwende ich immer einen Objekt-Relationalen Mapper. Dies ist nicht der einzige Weg aber ich finde es empfehlenswert da es so viel einfacher ist objektorientierte Technicken (Patterns, usw.) anzuwenden und deren Vorteile zu nutzen.
NHibernate und EntetyFramework sind bekannte ORMs, es gibt aber auch viele weitere (und auch viele die sich nur so nennen).
Ich empfehle dier einen bestehenden ORM zu wählen und sich mit einem Tutorial einzuarbeiten.
hab diesen Thread total vergessen. Das Problem hat ein Kollege von mir gelöst.
Damit Spalten angezeigt werden müssen sie beim C1TrueDBGrid nicht nur dem Grid sondern auch den Splits (sieh Property Splits) hinzugefügt werden.
100%ig kenne ich mich nicht mit AppDomains aus, aber du müsstest 2 Probleme haben:
1. So bald du Unwrapp auf das Objekt aus der anderen AppDomain anwendest wird dieses Objekt in die aktuellen AppDomain geladen. Das bedeutet, dass dein ganzer Schöner plan mit entladen und so weiter hinfällig wird, da die Assembly des PlugIns dann in der "Haupt"-AppDomain ebenfalls geladen ist!
2. Um MdiParent des PlugIns zu setzen muss die Form die du dort übergibst in die PlugIn-AppDomain übertragen werden. Das ist eventuell nicht möglich und löst Exceptions aus, die man fälschlicher weise mit Typen aus den PlugIn-AppDomains assoziiert stadt mit dem MdiParent aus der Haupt-AppDomain.
Ich denke dass man mit C# hier nicht so einfach zum Ziel kommt.
Auf CodeProject gibt es einen Window-Tabifier der das ganze über die Windows-API löst. Das hat seine eigenen Nachteil, löst aber das Laden und Entladen der Assemblies, in dem jedes PlugIn einen echten eingenen Windows-Prozess hat.
Ein anderer Ansatz der mir einfallen würde ist, dass man zum Übertragen der PlugIn's keine eigenen Form-Klassen verwendet (so wie der Windows-Forms-Designer) sie anlegt, sondern eine 0815 System.Windows.Forms.Form instanziiert und füllt (diese kann dann ja direkt in der Haupt-AppDomain erstellt werden). Wie man diese Form füllt ist aber eine gradwanderung zwischen Komplexität und Funktionalität und man müsste sich das gut durchdenken.
ich will die Sprache sprechen können :) da brauch ich keinen Volltextübersetzer.
Es ist eine künstliche Sprache für eine Computerspiel, daher dürfte sie nicht sehr vollständig sein aber mit ein paar Einschränkungen sicher nutzbar. ((Nur als Beispiel haben die Drachen in Skyrim eine andere Verbindung mit der Zeit als Sterbliche und daher hat ihre Sprache keine Zeiten!))
die Sprache der Drachen aus Skyrim gefällt mir und ich würde sie gerne lernen.
Alleine ist das aber schwer und man kann nicht üben, daher suche ich jemand der mit macht.
Ich stell mir das so vor, dass man über InstantMessenger oder so einfach mit einander spricht und versucht die Drachensprache zu verwenden.
Am Anfang wird das natürlich reichlich zerhackt und unschön sein, aber dafür versucht man's ja.
Wäre jemand interessiert?
Gruß
Juy Juka
Zitat
Dream yol lok,
thinvaakdovahii nol Skyrim brit wah zu ahrk Zu'u laan unt daar.
Vomu kos lot komeyt ahrk nis unt, Zu'u laan naan dreh.
Zu'u hahnu, mu thinvaak ahrk unt dreh thinvaakdovahii.
Saraan meyz pogaan krent ahrk vobrit, nuz daarii unt mu. Geh?
Naanii hind?
Lok, Thu'um
Juy Juka
[offtopic]@Moderatoren/Admins: Ich hoffe/denke, dass ein Computerspiel nicht zu weit weg ist für Smalltalk.[/offtopic]
also Typensicher geht es nur wie Rabban es vorgeschlagen hat (so weit ich sehe).
Wenn man aber auf die Typensicherheit verzichtet, kann man mit Reflection hier etwas machen.
Dazu muss man die Properties übergeben und nicht deren inhalt (so wie in deinem Code).
1. Als strings (einfach aber unschön).
2. Als Expressions (etwas schöner, aber trotz Intellisense und so weiter nicht typensicher).
also genau dieses Verhalten ist im SplitContainer implementiert, da er seine Teil-Panels automatisch ein und Ausklappen kann.
Genauso einfach kann man das mit einem Pannel auf Dock=Fill und einem zweiten Panel auf Dock=Left/Right machen, das Doch=Fill-Panel nimt automatisch den Platz des anderen mit ein, wenn man das Doc=Left/Right auf Visible=False setzt.
Den Inhalt in den Panels kann man mit einem TableLayoutPanel sauber gestalten oder (wenn man will) innen dann mit Anchor arbeiten.
Also insgesamt hätte man 0-3 Controls extra (je nach dem wie es jetzt schon aufgeteilt ist und welche ContainerControl man verwendet).
so weit mit bekannt ist Anchor nicht sehr performant/effektiv, daher vermeide ich es wan immer möglich. Das geht, da .Net auch noch eine zweite automatische Größenfunktion hat. Diese ist manchmal etwas umständlicher aber meistens (gefühlt) verständlicher und weniger Fehleranfällig.
Ich spreche über Dock, welches in Kombination mit Padding und Margin wunder bar funktioniert und im Designer eingestellt werden kann.
Man muss die Form nur mit Container-Controls (die unsichtbar sein können) sauber unterteilen (Panel, TableLayoutPanel, SplitContainer, ... etc.).
Also ich würde das ganze mal mit Dock=Fill und Margine={0,0,0,10} ausprobieren. ((Ich habs jetzt selber nicht versucht.))
wie Abt schon sagte ist hier in einem Forum-Post eine ausreichende Antwort zu geben so gut wie unmöglich. Aber wenn du die gegebenen Links durch liest, hast du gute Chancen die Antwort zu verstehen.
Einen Teil deiner Frage kann ich aber Beantworten: Forms + Klassen
Die Form ist in den meisten Fällen (nicht immer) die Präsentation zu einem oder mehreren Objekten, was bedeutet, dass Sie den Zustand der Objekte (aka. Properties) darstellen soll - Positionierung, Formatieren, etc.
Das Problem daran ist meistens aber mitzubekommen wann die Form "veraltet" ist, d.h. sich der Zustand der Objekte geändert hat. Hierzu verwendet .Net das Observer-Pattern im .Net-Framework durch INotifyPropertyChanged dargestellt. Und in Windos-Forms und in der WindowsPrestentationFoundation durch Databinding implementiert/verwendet. Ob das Verhalten/Methoden der Objekte jetzt von der Form angestossen wird oder anders ist und was für ein Objekt dargestellt wird ist nicht so wichtig.
Dann hätte ich aber lieber die Abfragen als Objekt (siehe DetachedCriteria/ICriterions) und so eine Schnittstelle zum einhacken in den ORM sollte besser im ORM sein und nicht "außernherum" gebaut. Aber dafür können die Leute die den ORM verwenden nichts. :)
Zitat von Abt
* Direktes Kompilieren der Queries -> Performance-Steigerun
Gilt ja nicht für jeden ORM.
Zitat von Rabban
•Man kann relativ einfach die Repositories austauschen wenn man die DB oder den OR-Mapper wechseln muss.
Also DB wechseln sollte der ORM können! Aber ORM wechselen ist ein Argument.
Zitat von Rabban
•das Repository Läd/Speichert immer nur mit Transaktionen, somit muss man das nicht immer expliziet bei jeder Aktion angeben.
Also das Transaktions-Handling sollten die Entwickler schon im Auge behalten, trotz aller Einfachheit und Abstraktion ist das so wichtig, dass mir es lieber ist wenn man es nicht ignoriert.
Zitat von Rabban
•Standardisierung beim Speichern von ApplicationNames wenn sich mehrere Anwendung die gleiche DB teilen.
danke für die Hilfe mit einer ICollection hat NHibernate es korrekt erkannt und nicht in der Datenbank aktualisiert.
Zitat von Rabban
... eine virtual IList<T> oder etwas vergleichbares nutzt ...
Richtig erkannt, wir wissen garnicht was für eine Collection da eigentlich drin steckt.
Zitat von Abt
...keine Repositories..
Zitat von Rabban
... Am sinnigsten wäre es aber wohl wirklich, wenn ihr euch ein Repository schreibt das die Collection zu dieser Entität in der Sortierung zurück gibt, wie ihr es braucht.
Somit wäre die neue Collection auch Lazy und ihr könnt darin wild rumsortieren oder verändern wie ihr wollt, ohne die Versionsnummer von Entität A zu verändern.
Wie Rabban sagte muss man keine Repositories in NHibernate verwenden. Aber dank der ganzen Optionen von NHibernate (Selekt-Bedingungen auf Typen-Ebene, Sortierkriterien, Vererbung, ...) und dem OO-Prinzip der Kapselung ist das ganze Konzept von Repositories eigentlich überflüssig! Weil:
- der Großteil aller Abfragen auf die Objekte sowieso dynamisch, je nach Benutzerwunsch/-eingabe, ist.
- nur wenige komplexe Bedingungen wiederverwendet werden müssen.
- die komplexen Bedinungen einfacher als eigene Implementationen von ICriterion (bzw. in den jeweiligen alternativen Abfrage-Syntaxen)* umgesetzt werden und so dynamisch an den passenden Stellen verwenden** werden können (statt Methoden aus Repositories).
Sehr viel Erfahrung mit NHibernate im speziellen und Repository-Pattern im Allgemeinen habe ich aber nicht. Falls jemand gute Gründe für das Repository-Pattern hat, würde es mich freuen sie zu lesen.
Gruß
Lecrell & Juy Juka
* wir verwenden nur DetatchedCriteria als Abfrage-Syntax, der Einfachkeit halber.
** dank Mikrokern/ServiceLocator kann man dies dann global Konfigurieren/Austauschen.
1. Das Browser-Steuerelement muss in einer Maske liegen.
2. Man kann weitere Steuerelemente in diese Maske einfügen.
3. Um dein Ziel zu erreichen fügst du am einfachsten ein Button-Steuerelement* ein und reagierst auf dessen Click-Event.
4. Wie du (im Click-Event) das Browser-Steuerelement zurück navigierst findest du in der Dokumentation des Browser-Steuerelements.
[offtopic]deine Sätze oben haben eineige böse Fehler/Lücken, du solltest das besser Korrigieren. Tipp: Texte immer noch mal komplett selber lesen, bevor man sie abschickt.[/offtopic]
Am einfachsten geht das, in dem du auf die Maske in der das Browser-Steuerelement ist eine ToolBar und/oder MenuBar einfügst und dort einen Knopf einbaust der den Browser auf die Anfangsseite zurück navigiert. (Wie das geht findest du in der Dokumentation des Browser-Steuerelements.)
anstelle der Delegaten gehen natürlich auch Interfaces.
Und wegen "Single Responsibility Prinzip": Sie es doch ehr so, dass die Klasse nicht für das Schließen verantwortlich ist, sondern für die Steuerung des Ablaufs, also der Klasse die wiederum für das Schließen verantwortlich ist rechtzeitig bescheid geben muss (ob über Methodenaufruf oder Event oder etc. ist hier dann ehr eine Frage wie lose oder eng man koppeln möchte).
seit heute plötzlich ist mein Visual Studio extrem langsam beim Start des Debuggers.
Gestern habe ich einen Symbolserver eingebunden um NHibernate zu debuggen und das hat auch funktioniert, daher vermute ich, dass er immer noch versucht Sysmbole online nachzuladen.
Ich habe alle "Orte für Symboldateien" unter Extras -> Optionen -> Debugging -> Symbole deaktiviert, kontrolliert dass ich keine _NT_SYMBOL_PATH oder _NT_ALT_SYMBOL_PATH Umgebungsvariable habe und Extras -> Optionen -> Debugging -> Allgemein -> Nur eigenen Code aktivieren (nur verwaltet) aktiviert.
Scheinbar lädt er aber immer noch Symbole von irgend wo her (außer dem Ausführungsverzeichniss).
Weis jemand wie ich Symbolserver wirklich lösche?
Kennt jemand einen anderen Grund warum das Debugging so langsam startet?
stimmt, wenn die Unterklasse neu ist, ist es kein BreakingChange, weil die Unterklasse ja noch nicht verwendet wird.
In meinem Fall ist es aber ein BreackingChange da die Unterklasse nicht neu ist, sondern die Warning durch das vergessene new/override nicht aufgefallen war. Es wird die Klasse also schon sehr oft verwendet und auch als Konkreter Typ.
Und gefühlt ist es das auch in den überwiegenden Fällen ein BreackingChange, da man ja nicht weiß wo/wer auf das Property/die Klasse zugreift so bald man es einmal Veröffentlicht hat und sich (wie Sarc gezeigt hat) das Verhalten ändert.
man muss im DataGridView die Spalten definieren, dann kann man Reihenfolge, Formatierung und noch viel viel mehr beeinflussen.
Wenn man den DataGridView einfach alles automatisch machen lässt, hat man da sehr wenig einfluss.
Dank Sarc ist jetzt klar, dass es ein BreakingChange ist und ich werde es nicht ändern. new werde ich einfügen, da es die Warnung "behebt" aber eh keine Auswirkung auf den Programmablauf/die Auflösung der Member hat, danke ujr.
Tja, Console32, hat recht, dieses Verhalten war sowieso keine Absicht und wurde leider übersehen. Da es aber trotzdem Funktioniert und ich im Notfall auch an das Property der Basis-Klasse komme, kann ich es so belassen.
hoffentlich habe ich ein solche Thema nicht mit/in der Suchfunktion übersehen.
Ich habe ein Property* in einer Klasse und in einer davon erbenden Klasse mit dem gleichen Namen* deklariert, was ja nur eine Warnung im Compiler verursacht. Die Assembly mit diesen beiden Typen ist raus und in verwendung. Wenn ich jetzt diese Warnung beheben will müsste ich das virtual des Properties in der erbenden Klasse in ein override ändern.
Wäre das ein Bracking-Change? Und wenn ja warum? Und was würde das hinzufügen von new vor das virtual verursachen?
Gruß
Juy Juka
* es könnte genauso gut eine Methode sein, dann müsste halt Name und Signatur übereinstimmen.