Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Portal
  • |
  • Mitglieder
Beiträge von Peter Bucher
Thema: DI/IoC in der Praxis (und korrekter Aufbau der zugehörigen Klassen)
Am im Forum: Rund um die Programmierung

Salute haarrrgh

Wieviele direkte Erzeugungen von Instanzen siehst du hier?


public class Auftrag
{
    public void NeuerAuftrag (int KundenNr, string ArtikelNr)
    {
        var kundeRepo = new KundeRepository();
        var artikelRepo = new ArtikelRepository();

        Kunde kunde = kundeRepo.Get(KundenNr);
        Artikel artikel = artikelRepo.Get(ArtikelNr);

        // und jetzt wird ein neuer Auftrag erzeugt, und
        // dabei auf die Properties von kunde und artikel zugegriffen...
    }
} 

Ich sehe genau zwei: kundeRepo und artikelRepo.
Diese Erzeugungen sollten zur Sicherstellung der Testbarkeit ausserhalb dieser Methode passieren und übergeben werden.

Ich würde - da ich noch weitere Konsumenten dieser Instanzen vermute - die Repositories als readonly-Membervariable der Klasse "Auftrag" hinterlegen und diese zu injizieren. Meine bevorzugte Variante ist die Constructor-Injection.

Dann kommen wir zu:

Kunde kunde = kundeRepo.Get(KundenNr);

Hier fungiert - wenn du so willst - das "kundeRepo" als Fabrik für deinen Kunden.
Die Fabrik wird injiziert, das heisst du hast Kontrolle darüber, wie sich die Fabrik verhält und was sie zurückgibt.

Dies ist also eine indirekte Erzeugung und muss nicht direkt von Aussen injiziert werden, auch nicht um die Testbarkeit sicher zu stellen.

Wenn du den Kunden / Artikel auf irgend eine Art verändern / faken willst oder musst - aus welchen Gründen auch immer, nutzt du in der Methode eine Abstraktion und kannst dann in deinem Test-Repository, das du reingibst, die gewünschte Implementation erzeugen.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Hallo zusammen

@herbivore
Als Nebenbemerkung finde ich die Sache mit Priorität auf Lesbarkeit, auch weil der Code sowieso optimiert wird, passend und sinnvoll.

Ich denke somit ist alles gesagt, mehrfach :-)


Gruss Peter

Thema: iPhone/iPod Verbindung und Musik-Titel abrufen
Am im Forum: Rund um die Programmierung

Salute Tobi

Ich glaube nicht, das es eine solche - offizielle - Schnittstelle gibt.
Was meinst du mit "Musik-Titel abrufen"?

Die Titel als Text, oder die Lieder als Dateien?


Gruss Peter

Thema: DI/IoC in der Praxis (und korrekter Aufbau der zugehörigen Klassen)
Am im Forum: Rund um die Programmierung

Salute Andre

Ach so meinst du das :-)
Eine sehr gute Lösung und auch ein Beispiel für eine sinnvolle Zusammenarbeit / Nutzung von einem DI-Container und Factories.


Gruss Peter

Thema: DI/IoC in der Praxis (und korrekter Aufbau der zugehörigen Klassen)
Am im Forum: Rund um die Programmierung

Hallo Andre

Ach so, da habe ich zu wenig weit gedacht :-).
Mit extra Methode meinst du eine Factory-Methode, oder wie kann ich mir das vorstellen?


Gruss Peter

Thema: DI/IoC in der Praxis (und korrekter Aufbau der zugehörigen Klassen)
Am im Forum: Rund um die Programmierung

Hallo Andre

Zitat von VizOne
Auch wenn die meisten DI-Container beim Aufruf von Resolve die manuelle Übergabe von Parametern zulassen, rate ich persönlich davon ab, da meist mit Strings gearbeitet wird, um den Parametern Werte zuzuweisen, was leicht zu Laufzeitfehlern führt und schlecht zu refaktorisieren ist.
Strings? Beim Resolve-Aufruf?

Strings werden wenn, dann in der Xml-Konfiguration benutzt.
Beim Resolve-Aufruf kannst du das Argument typisiert übergeben und hast dadurch keine Refaktoring-Probleme.

Natürlich können da Runtime-Fehler auftreten, aber das geht nicht anders.
Und auch ist es klar, das man damit ein bisschen Unabhängigkeit auf den konkreten Typen verliert. Allerdings muss das nicht tragisch sein, wenn man das Wissen hat, das alle erbenden Klassen, die selben Argumente erwarten.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Salute herbivore

Okay, das macht es klarer :-)


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Hoi herbivore

Zitat von herbivore
eine vollständige Einheitlichkeit der - ich nenne es mal Gestaltung - von Code wird es nie geben. So wie man da mit klarkommen muss, dass manche die öffnende geschweifte Klammern ans Ende der Zeile setzen und andere an den Anfang der folgenden oder manche zuerst set und dann get schreiben statt anderherum, wird man auch damit leben müssen, dass mache - auch in Zukunft - ++i schreiben und andere i--.
Theoretisch kann er das, nur ist das praktisch fast nicht zu 100% umsetzbar. Damit leben muss man nicht, zumindest nicht, wenn man das unter seiner Kontrolle hat.

Privat habe ich als Ziel 100% zu erreichen, im Geschäft auch. Privat werde ich das mit sehr viel Aufwand fast erreichen, im Geschäft nicht.
Aber das ist auch egal, denn 80% sind besser als 0% und 100% sind ein besseres Ziel als pessimistisch hinzugehen und zu sagen: "Du musst damit leben".
Zitat von herbivore
Wie schon ziemlich zu Anfang gesagt, stört es mich nicht, wenn jemand i++ schreibt.
Okay, aber inwiefern ist das relavant für die Diskussion?


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Salute Robin

Zitat von RBA285
Ich denke beide Lösungen sind o.k., der Lesbarkeit tut es in Summe keinen
Abbruch, da dass inkrement bei der Analyse fremden Codes das kleinste Problem
hinsichtlich der Lesbarkeit darstellen dürfte.
Nunja, die Summe von kleinen Hindernissen hinsichtlich der Lesbarkeit ergibt dann auch ein grosses Hinderniss.
Und wie das mit den Ausnahmen so ist. Entweder ist man richtig lazy oder richtig strict.

Das ist jetzt zwar ein wenig radikal und aufs Detail geschaut. Muss es meiner Ansicht nach auch sein, da man sonst schnell in die lazy-Richtung geschoben wird.


Gruss Peter

Thema: ASP.NET Erstellen von PNG Image erzwing Save-Dialog
Am im Forum: Web-Technologien

Hallo zusammen

Zitat von MarsStein
Warum Du lokal einen Dialog dafür bekommst, ist wohl eher eine Einstellung des Browsers (Zoneneinstellung/Komatibilitätsmodus??)
Ja genau.

Wenn du - DomiOh - keine weiteren Angaben über den Content-Disposition Header machst, greift die Standard-Einstellung des Browsers.

Also am besten den Header mit einer expliziten Angabe zum Speichern oder Anzeigen mitgeben.
So müsste es in den meisten Fällen beim Client auch passen. Ausser die Clients ignorieren deinen Header oder setzen die Priorität des Headers niedriger als eigene Einstellungen.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Hallo zusammen

Zitat von Golo Roden
Punkt ist einfach: Es hat sich halt so etabliert, vermutlich, weil die meisten Beispiele für Schleifen mit i++ und nicht mit ++i arbeiten, und weil C++ nun mal C++ heißt und nicht ++C, und dabei ist es dann einfach geblieben.
Womit du mein letztes Posting nochmals unterstreichst.

Ich kann somit alle Parteien verstehen und als Fazit ziehen, das eben dieser Knackpunkt mit der Etablierung entscheidend ist, und eine theoretische Analogieüberlegungen in der Praxis irrelevant ist.


Gruss Peter

Thema: [erledigt] Garbage Collector - Methodendesign
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Salute Beppo

In deinem Fall ist es noch einfacher zu erklären / begründen.
Deine Person ist eine lokale Variable. Wenn der Gültigkeitsbereich der lokalen Variable (Methoden Body) verlassen wird, ist sie nicht mehr gültig / vorhanden bzw. wird abgeräumt.

Allerdings nur, wenn du nirgendwo sonst eine Referenz darauf hast, wie MarsStein schon angemerkt hat.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Hoi Golo

Zitat von Golo Roden
Postfix sind die meisten Entwickler gewohnt, Präfix nicht [...]
Ich glaube das ist der Knackpunkt.

Unbewusst nutzt der Entwickler ja sehr viele Prefix-Operatoren, wie bspw. die Negation eines Ausdruckes.
Also könnte man daraus schliessen, das Präfix-Operatoren üblicher, gewohnter und natürlicher sind - was herbivore hier anscheinend meint.

Jedoch ist es an der Stelle einer Inkrementation eben nicht so.
Ich sehe das getrennt an, also alles andere und die Inkrementation. Und die Inkrementation ist als Postfix gebräuchlich und am verbreitesten.

Und das entgegen dem eigentlich viel häufigeren Gebrauch von Präfix-Operatoren im allgemeinen.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Salute zusammen

Oh, so ein Glaubenskrieg wollte ich nicht auslösen, ich dachte nicht dass es so eine Zweiteilung gibt.
Herbivore hat mir angekreidet, das ich zuwenig argumentiert habe.

Also, eigentlich ganz einfach:
Ich finde den Postfix-Operator lesbarer, Gründe wurden auch schon genannt, wie bspw. der natürliche Lesefluss.
Der wichtigste Grund ist für mich aber, dass der Postfix-Operator am bekanntesten ist, am häufigsten benutzt wird und in einigen Sprachen der einzig existente ist.

Das heisst: Wenn ich irgendwo den Prefix-Operator benutze, können andere damit Schwierigkeiten bekommen, was für mich auch mit der Grund ist, möglichst überall den Postfix-Operator zu nutzen, denn es geht auch ganz ohne Prefix-Operator.

Der einzige technische Unterschied vom Pre- zum Postfix-Operator ist AFAIK ja, dass der Ausdruck "++i" selber dann schon um eins erhöht wird, hingegen bei "i++" nicht der Ausdruck selber, sondern die Variable "i" beim nächten Gebrauch inkrementiert ist.
Das mag in manchen Fällen einfacher / simpler zu schreiben sein (Eine statt zwei Zeilen / oder das Ausdrücke nicht auseinander "gerissen" werden müssen, nur um den Postfix-Operator nutzen zu können.

Im Fazit geht bei mir die Lesbarkeit vor. D.h. ich verwende den Prefix-Operator sehr, sehr selten.

@herbivore
Technisch, akademisch kann deine Argumentation verstanden werden und ist auch korrekt. Es scheint das wir unterschiedliche Prioritäten haben.


Gruss Peter

Thema: Postfix oder Prefix Schreibweise um eine Variable zu inkrementieren?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Hallo esskar

Da kann ich dir leider nicht zustimmen.
Die erste - originale - Variante ist m.E. am lesbarsten. Die zweite ist korrekt, aber weniger lesbar.
Die dritte ist auch korrekt, allerdings ist "++this._index" in diesem Fall unnütz, sodass du gleich "this._index++" schreiben kannst.


Gruss Peter

Thema: LightCore: Aggregierte Klasse benötigt Konstruktorparameter, Aggeregierende aber nicht
Am im Forum: Rund um die Programmierung

Salute Stefan

Wenn du die Argumente zur Laufzeit übergeben willst, kannst du das auf die natürliche Art machen ;-).

Durch diesen Aufruf hast du die grösste Flexibilität, jedoch verlierst du hier die "AutoWiring"-Funktion von LightCore, d.h. das LightCore Foo und Bar selber einsetzt.
Dies kannst du nur behalten, wenn du das zur Registrierungszeit festlegst.

var fooBar = c.Resolve<FooBar>(c.Resolve<Foo>("Hallo"), c.Resolve<Bar>(23));


Gruss Peter

Thema: Bug in LightCore? (ThreadSingletonLifecycle)
Am im Forum: Rund um die Programmierung

Hallo mouk

Das ursprüngliche Beispiel ist in meinen Augen fehlerhaft.
Wenn die Variable als Thread-affines Singleton definiert wird, ist es ja per se verboten, diese in mehr als zwei Threads zu nutzen.

Wenn Du das - per Tricks wie hier mit einer Captured Variable - doch machst, hebelst Du die Eigenschaft der Thread-Affinität aus und "missbrauchst" LightCore ja quasi. Dass das nicht funktioniert, ist klar.

Ist in meinen Augen aber kein Bug, weil falsche Voraussetzungen gegeben sind.

(Wenn ich auf ein Objekt in einer WeakReference noch eine zusätzliche Referenz halte, wird das auch nicht richtig abgeräumt - da kann die WeakReference dann aber auch nichts für ;))

Auch ist es in meinen Augen nicht klar, ob der Thread mit dem Setzen auf null und einem Absetzen von GC.Collect(2) wirklich abgeräumt wird.

Ein Thread.Abort() würde diese Aufgabe vermutlich sauberer lösen.

In meinen Augen ist das kein offensichtlicher Fehler, da das Beispiel relativ konstruiert ist und das fehlende Abräumen von Instanzen nicht direkt als Fehler sichtbar ist.


Gruss Peter

Thema: Wo genau Extension Methods einsetzen, wo besser eigene Klassen?
Am im Forum: Rund um die Programmierung

Hallo zusammen

Ich stimme hier zu, das Extensionmethods primär als sinnvolle, projektinterne Erweiterung für Typen sind, die sonst nicht zugreifbar sind.
So eine Art Short-Cut / Syntactic Sugar.

Die Extensionmethods sollten auf jeden Fall in einem Projektbezogenen Namespace sein (Ausser es handelt sich um ein Framework).

Da muss man aufpassen, das beim Zusammenführen von Bibliotheken, oder nur schon der gemeisamen Nutzung keine Konflikte auftreten, die dann mühsam sind und teilweise auch verwirren können.


Gruss Peter

Thema: LightCore - StackOverflowException bei Verwendung des eigenen Typens als Parameter im Konstruktor
Am im Forum: Rund um die Programmierung

Hallo mouk

Der erste Bug ist gefixt und ins SVN Repository eingecheckt.
Wenn alle bekannte Bugs gefixt worden sind, gibt es einen neuen Release.

Fixed ReflectionActivator uses non public constructors bug.
see: (LightCore - StackOverflowException bei Verwendung des eigenen Typens als Parameter im Konstruktor).

Beschreibung:
LightCore ruft nur noch öffentliche Konstruktoren ab.

Dem zweiten Problem widme ich mich Morgen.


Gruss Peter

Thema: Bug in LightCore? (ThreadSingletonLifecycle)
Am im Forum: Rund um die Programmierung

Hallo mouk

Der Bug ist gefixt und ins SVN Repository eingecheckt.
Wenn alle bekannte Bugs gefixt worden sind, gibt es einen neuen Release.

Fixed ThreadSingleton does not release references after thread exit bug.
see: (Bug in LightCore? (ThreadSingletonLifecycle)).

Beschreibung:
Ich habe das Problem so gelöst, das Lifecycle-intern nicht das Object (object) referenziert wird (Im Dictionary gehalten), sondern eine WeakReference davon.

Das wars schon :-)


Gruss Peter

Thema: LightCore - ResolveAll<T>().ToArray() wirft InvalidOperationException
Am im Forum: Rund um die Programmierung

Hallo Uwe

Der Bug ist gefixt und ins SVN Repository eingecheckt.
Wenn alle bekannte Bugs gefixt worden sind, gibt es einen neuen Release.

Fixed ResolveAll throws InvalidOperationException bug.
see: (LightCore - ResolveAll<T>().ToArray() wirft InvalidOperationException).

Beschreibung:
Wieso das es mit nur einer Registrierung krachte, jedoch mit zwei nicht, ist mir immer noch ein Rätsel.
Das Verhalten sollte eigentlich bei beiden das gleiche sein.

Ich konnte es auch nachvollziehen, jedoch nach meiner Änderung nicht mehr.

Schlussendlich lag es daran, das beim Aufruf von ResolveAll, ein bis mehrmals intern Resolve aufgerufen wird und dieser Aufruf die Auflistung mit den Registrierungen geändert hat (Registrierung hinzugefügt).

Die Lösung war, die Enumeration am Anfang von ResolveAll per .ToList() zu kopieren, sodass die sich nicht in die Quere kommen, d.h. es egal ist, wenn die Original Enumeration geändert wird.


Gruss Peter

Thema: LightCore - ResolveAll<T>().ToArray() wirft InvalidOperationException
Am im Forum: Rund um die Programmierung

Hoi Uwe

Ich habs mal kurz angeschaut (Ohne Debugging).
Der Fehler tritt nur auf, wenn ein "IBar" registriert ist, ab einer Anzahl von mehr als 1 läufts.

Melde mich später wieder, wenn ich den Fehler gefunden habe :).

Jetzt schon vielen Dank für die Rückmeldung!


Gruss Peter

Thema: LightCore - StackOverflowException bei Verwendung des eigenen Typens als Parameter im Konstruktor
Am im Forum: Rund um die Programmierung

Hallo mouk

1. Da hast du vollkommen Recht und leicht zu ändern.
2. An der Sache mit den zyklischen Abhängigkeiten muss ich mal rangehen. Priorität haben aber erst mal die anderen Bugs.


Gruss Peter

Thema: LightCore - StackOverflowException bei Verwendung des eigenen Typens als Parameter im Konstruktor
Am im Forum: Rund um die Programmierung

Hallo mouk

Vielen Dank für deine Meldung.
Welches Verhalten würdest du denn erwarten?


Gruss Peter

Thema: Methode aus dem .NET Framework anpassen/erweitern/verändern
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Salute zommi

Hmm, sowas müsste doch eigentlich ohne Änderung des Frameworks möglich sein.
Entweder arbeitest du direkt mit DynamicMethod, ohne Expression Trees, oder aber du fügst deine gewünschte DynamicMethod in den Expression-Tree als Konstante rein (Expression.Constant).

Ansonsten wäre ein Beispiel deiner versuchten Anwendung nützlich.


Gruss Peter

Thema: Ein Bug bei LightCore (2)? (ReflectionActivator)
Am im Forum: Rund um die Programmierung

Hallo mouk

Zitat von mouk
Da mein letzter Beitrag nicht beantwortet wurde, bin ich mir nicht mehr sicher, ob das Forum der richtige Ort für Bugreports. Gibt mir bitte Bescheid, falls ich die Beiträge hätte woanders posten sollen.
Vielen Dank für deine Bugreports!
Der Ort passt soweit, ich bin bisher nur noch nicht dazu gekommen mich darum zu kümmern.


Gruss Peter

Thema: control.ID, control.ClientID, control.Unique.ID = Alles dasselbe?
Am im Forum: Web-Technologien

Hoi Schuppsl

Zitat von schuppsl
Ja, soweit klar und genau darin besteht mein Problem!
Ich rufe die Render Funktion(welche meine Controls erzeugt) im Page_Load auf und müsste dann also im Page_PreRender die Controls suchen und dann die ID auslesen.
Aber wie kann ich diese finden, wenn ich nicht mal die ID kenne?
Zwickmühle.
Ich sehe dein Problem nicht wirklich.

Den Vorschlag von MarsStein ist kein Workaraound, sondern eine Lösung,
so wie ich das verstehe :-)
Zitat von schuppsl
Ok, den Namespace "tools" habe ich im Codefile (reines codefile) schonmal nicht...also geht Ansatz 1 nicht.
Bitte ganz unten schauen, dort gibts das Beispielprojekt zum Download.


Gruss Peter

Thema: control.ID, control.ClientID, control.Unique.ID = Alles dasselbe?
Am im Forum: Web-Technologien

Salute schuppsl

Was genau hast du den am Artikel nicht verstanden?
Ich denke eher das dir der Realisierungsteil fehlt oder unvollständig erscheint.
Schau dir hierzu mal folgenden Post an, der mehrere Möglichkeiten enthält, um an die ID zu kommen:
- http://www.aspnetzone.de/blogs/peterbucher/archive/2008/09/02/zwei-ans-tze-wie-mit-den-clientids-von-asp-net-umgegangen-werden-kann.aspx

Es gibt zwei wichtige Punkte:
- Das Control muss in die Hierarchie eingehängt werden (Am besten im OnInit, spätestens in OnLoad). Dabei ist zu beachten, das man wirklich am Root hängt, sowas nützt also nix:


Control test = new Control();
Label label = new Label();

test.Controls.Add(label);

sondern erst, wenn man sich komplett an die Page dranhängt, oder an ein Control das schon an der Page hängt.


this.Page.Controls.Add(test);

- Werden die IDs erst kurz vor PreRender erzeugt (wenn der obere Punkt passt), also erst von diesem Zeitpunkt an, ausgelesen und genutzt werden können.

HTH


Gruss Peter

Thema: DropDownList.SelectedIndex liefert falschen Wert
Am im Forum: Web-Technologien

Salute zusammen

Zitat von aequitas
Das ist nicht unsauber, das ist die normale Vorgehensweise.
Da stimme ich bei.
Die Benutzung von "value" ist so gedacht. Was für Werte du da reinpackst ist egal.


Gruss Peter

Thema: a href ohne javascript in einer DataList?
Am im Forum: Web-Technologien

Hoi s0h0

Wenn dein <a href Link ohne "runat="server"" im Template steht,
sollte alles so bleiben, wie du es definiert hast.

Zeig doch bitte mal die relevanten Ausschnitte aus deinem Projekt.


Gruss Peter