Tja ... das ist halt wieder so .... hach, irgendwie nicht so richtig elegant. Aber es läuft wohl darauf hinaus.

Danke für die Antwort. Das funktioniert so wohl - finde ich aber nicht sonderlich elegant, weil man den Code halt doch mehrfach braucht ...

Hallo,

ich habe ein System mit User- und Group-Objekten, wobei es jeweils an User eine Eigenschaft Groups und an Group eine Eigenschaft Users gibt, jeweils vom Typ IList<>.

So weit, so gut. Funktioniert auch alles.

Nun möchte ich wissen, ob eine Gruppe einen bestimmten Benutzer enthält - ist ja prinzipiell nicht schwer:

var isUserInGroup = group.Users.Contains(userX);

Das Blöde ist nun aber, dass ich für userX genau das Objekt reingeben muss, das in der Gruppe gespeichert ist. Was ich aber gerne hätte, wäre, dass die beiden Objekte inhaltlich verglichen werden - im Idealfall nur, ob das Feld namens ID übereinstimmt.

Wie könnte man so etwas lösen, ohne für Groups und Users jetzt jeweils eine Ableitung von List samt Überladung von Contains schreiben zu müssen?

Viele Grüße,

Golo

Quellcode: Okay, das ist ein Argument.

Wäre es möglich, über den Client SMS auch wieder zu empfangen?

Besteht zudem die Möglichkeit, den Quellcode zu bekommen?

Kann mich Peter nur anschließen - habe auch vier Server bei QH, und die sind echt topp 😃!

Allerdings gilt das MSDN-Angebot nur noch bis heute (31.12.) ...

Schreib doch ne kleine Verwaltungs-UI für die XML-Datei ....

Von den beiden genannten Varianten: Nr. 1

was kostet ein Server, auf dem Umbracco auch läuft? Ist das für einen privaten Menschen auch bezahlbar?

Ja. ZB dieser hier für 15 Euro im Monat: http://www.qualityhosting.de/produkte/virtual-dedicated-server/msdn-hyperv/

Drupal ist PHP ... 😉

Für privat, KMUs, Vereine, ...: Umbraco
Für große Firmen: axCMS

Indem Du es per Hand ausführlich runterschreibst.

Entweder musst DU es machen oder Du überlässt es einem AOP-Framework. Eine andere Möglichkeit, die quasi "magisch" arbeitet, gibt's nicht 😉

Hallo,

ich möchte auf einer WPF-Form einen Rotating Donut anzeigen - wohlgemerkt, als Control, nicht als Mauscursor!

Prinzipiell ist das ja nicht schwer, zwei Ellipsen, bissle Farbverlauf, RenderTransform mit Rotate und fertig.

Nun möchte ich mir die Arbeit aber nicht machen, wo es das Ding ja in Vista schon fertig gibt. Hat jemand eine Idee, wie man das in WPF als Control einbinden kann?

Alternativ: Kennt jemand ein gut (!) aussehendes äquivalentes Control für WPF?

Viele Grüße,

Golo

Gibt es auf meine Frage eine Antwort bzw. ist das überhaupt möglich?

Mit aspektorientierter Programmierung bekommt man so etwas hin ... sieh ebeispielsweise www.postsharp.org ...

Oh, gut zu wissen, danke 😃!

Dass hier kein https verwendet wird, macht das ganze ebenfalls unsicher. Auf die Art ist es für einen Angreifer nämlich problemlos möglich, die Verbindung mitzusniffen und die von Dir übertragenen Credentials (egal ob Klartext oder nicht) zu verwenden.

Wenn es wirklich sicher sein soll, https + ein richtiges SSL-Zertifikat (ggf EV), um MITM-Attacken zu vermeiden.

Prinzipielles Vorgehen für eine sichere Verbindung:

• HTTPS + SSL(EV)-Zertifikat
• Kennwörter hashen und nur gehashed in der DB ablegen

Lässt man Schritt 1 weg, ist die Verbindung als unsicher zu betrachten und kann gehackt werden.

Lässt man Schritt 2 weg, ist die DB als unsicher zu betrachten.

Und ja - ich hatte diesen Fall schon mal ...

Entweder das, oder weise die entsprechenden Properties per Hand zu.

Es ist so, wie herbivore schrieb: Die Laufzeit zählt, nicht die Auslastung.

Das heißt, es ist egal, ob man die VM 30 Tage unter Volllast ackern lässt, oder 30 Tage eine Webseite bereitstellt, die null Mal abgerufen wird - beides kostet das gleiche.

Okay, diese Eigenschaft(en) kannte ich noch nicht, interessanterweise ändert es aber auch nichts, wenn ich DefaultConnectionLimit erhöhe.

Stimmt, das wäre eine Option ...

Okay, bei Windows Forms kannst Du beides nehmen. Bei ASP.NET sollte man den ThreadPool nicht verwenden.

Hallo,

ich möchte programmatisch prüfen, ob eine Webseite verfügbar ist. Meine Idee war, per HttpWebRequest eine Anfrage abzusetzen, und zu prüfen, ob eine Exception fliegt oder nicht.

Damit bekomme ich schon einmal heraus, ob die Domain existiert, ob ein Timeout geschieht, ...

Nun habe ich aber drei Probleme:

1. Mein Provider (T-Online) meint, im DNS-Fehlerfall eine eigene Seite liefern zu müssen ... dadurch fliegt keine Exception, sondern es wird eine Seite abgerufen - nur halt nicht die, die ich haben wollte.

2. Wenn ich das ganze in einer Schleife ausführe, habe ich immer nach zwei WebRequests eine merkwürdige Kunstpause - woran könnte das liegen?

3. Wie kann ich den HTTP-Statuscode mit in die Prüfung einbeziehen?

Oder insgesamt gefragt: Wie kann ich das intelligenter lösen als mit einem HttpWebRequest?

Viele Grüße,

Golo

Kommt drauf an, was Dein Host ist: ASP.NET, Windows Forms, ...

DateTime ist eine Struktur (und somit ein Valuetype), rptCustomers ist eine Klasse (und somit ein Referenztyp).

Du musst Equals explizit überschreiben, zudem solltest Du auch == und != überschreiben.

Hallo,

wie unter Erreichbarkeit von Webseiten überwachen? schon mal ähnlich gefragt, suche ich eine Software, die folgendes kann:

• HTTP, HTTPS, FTP, SMTP, POP3 und IMAP auf Erreichbarkeit überwachen
• Zusätzlich Ping zum Überwachen der Erreichbarkeit
• Anwendung läuft als Dienst permanent im Hintergrund
• Konfigurierbarkeit über UI
• Statussymbol im Tray
• "Toast" bei Statuswechsel
• Benachrichtigung per E-Mail und SMS
• Opensource
• .NET-basiert

Kennt jemand so etwas und kann etwas empfehlen?

Viele Grüße,

Golo

Dann ist es doch relativ simpel:

Equals, == und != überladen, und zusätzlich eine Methode IsInInitialState oder so einführen, in der folgender Code drinsteht:

return this == new MyType();

Angenommen, ich setze eine Property auf irgendeinen Wert und danach wieder auf null.

Ist das Objekt dann immer noch im Standardzustand (in Deinem Kontext)?

Anders formuliert: Geht es Dir darum, zu wissen, ob überhaupt schon einmal irgendwas damit gemacht wurde, oder nur darum, ob alle Properties die gleichen Werte wie ein neu initialisiertes Objekt aufweisen?

Mache ich in der Regel auch so. Wenns mir dann zu viele werden und diese alle Verwandt sind (z.B. alles EventArgs) dann kommen die auch mal in einen Ordner und bekommen ihren eigenen Namespace. Wobei man sich auch darüber streiten könnte ob z.B. EventArgs in einen eigenen Namespace kommen sollten.

Sollten sie nicht. Genauso wenig wie Exceptions.

Beides macht nämlich für den Verwender der API keinen Sinn, wenn er - um eine (1) Klasse zu nutzen - wegen EventArgs und Exceptions plötzlich noch zig weitere Namespace importieren darf.

Hallo,

Du solltest Dich mal mit folgenden Themen beschäftigen:

• Sessions (serverseitig)
• Cookies
• Verschlüsselung
• HTTPS

Allein der Satz

Also der User gibt Nickname und PW in ein Formular ein, die Daten werden dann mit einer der unzählbaren Möglichkeiten an ein PHP-Skript gesendet.. soweit, so gut. Verschlüsselung ist dabei wohl noch keine nötig, ein Browser bedient HTML-Formulare ja meist auch unverschlüsselt (oder irre ich mich?), selbst wenn es um Logins geht.

deutet darauf hin, dass Du noch einiges nachzuholen hast, wenn Du einen sicheren Login haben willst (und das ist nicht böse gemeint, sondern nur eine Feststellung).

Viele Grüße,

Golo

Nur um das kurz klarzustellen: Ja, Golo Haas und Golo Roden sind ein- und dieselbe Person - einmal vor und einmal nach der Hochzeit 😉.

Wenn Du die Hilfsklasse nicht direkt testest, sondern deren Funktionalität quasi durch den Aufruf der Hauptklasse testest, hast Du streng genommen keine Unittests mehr, sondern Integrationtests ...

Insofern: Hilfsklasse gesondert testen (alleine schon, weil es ja doch sein könnte, dass sie mal von jemand anderem verwendet wird), und gegebenenfalls zusätzliche Integrationtests bauen.

Hallo,

ja, es geht anders: Stichworte "Events" oder "Dependency Injection".

Die Frage, die sich mir als erstes stellt, ist, ob das Konstrukt mit den verschiedenen Hilfsklassen so sinnvoll ist ... Hilfsklasse haben immer so einen merkwürdigen Beigeschmack.

Hast Du mal ein konkretes Beispiel, wo Du das so machst?

Viele Grüße,

Golo

Abgesehen davon ist "123" wesentlich performanter als ein 123.ToString() ...

Hallo,

erstens: CommandsList halte ich für unglücklich, das ist unüblich, und sollte laut Microsoft so auch nicht gemacht werden. Ausnahmen wie ArrayList gibt es zwar, es sollte aber vermieden werden. Commands wäre dann prinzipiell schon richtig.

Zweitens: Ich halte den Ansatz, eine Commands-Klasse zu haben, und darin dann einzelne Methoden wie Join, ... (die ja eigentlich ein Kommando repräsentieren) für falsch. Löst man dieses Problem anders, erübrigt sich auch die Überlegung mit Commands.

Als Vorschlag: Ein Interface ICommand, das eine Methode Execute() besitzt, sowie eine abstrakte Basisklasse CommandBase, die dieses Interface implementiert. Des weiteren gibt es dann davon abgeleitete spezialisierte Klassen wie JoinCommand, ... die Execute implementieren.

Die Commands-Klasse wäre dann letztlich nur ein IEnumerable<ICommand> ...

Viele Grüße,

Golo

Vorname? Nachname? Fullname? Wenn Fullname, in welchem Format? Was passiert, wenn die ID nicht existiert? Kommt null zurück? Eine Exception? ...?

Ich kommentiere in meinen Projekten alles - lokale Variablen, private ebenso wie öffentliche Member.

Erstens hilft es dem eigenen Verständnis.
Zweitens hilft es dem Verständnis im Team.
Drittens muss ich dann nicht Kommentare nachziehen, wenn sich die Sichtbarkeit mal ändert - sprich, es ist von vornherein konsistenter.

Edit: Kleine Korrektur - lokale Variablen nur bedingt. Aber alles, wo man einen XML-Kommentar dranpacken kann, da schreibe ich ihn dazu.

Naja, man kommentiert ja aber auch für sich selbst und für Teamkollegen - das kann sich kein Mensch alles dauerhaft merken ...

Ich weiß es nicht 100%ig, aber ich würde mal auf einen "Schlemiel the Painter"-Algorithmus in Vista tippen ... siehe http://en.wikipedia.org/wiki/Schlemiel_the_painter's_Algorithm

Siehe auch http://www.joelonsoftware.com/articles/fog0000000319.html

Womit StyleCop ja auch recht hat ...

Wie schon gesagt - für jeden Typ eine eigene Datei.

PS: Eigentlich müsste man sogar sagen, eine Datei für jeden Typ (!), und nicht nur für jede Klasse.

Also eine Datei für jede

• Klasse
• Interface
• Enum
• Struct
• ...

Außerdem - angenommen, Du hast 20 EventArgs-Klassen, die nur aus drei Zeilen besteht. Jetzt kommt eine 21. dazu, die wesentlich umfangreicher ist.

Was machst Du nun?

Zwei Dateien? Eine Datei? Einundzwanzig Dateien?

Spätestens an diesem Punkt wird's arbeitsaufwändig und unnötig komplex.

Wie gesagt, die oben genannten Quellen empfehlen allesamt ohne Ausnahme eine Datei pro Klasse - und das ja nicht ohne Grund 😉.

Das Argument mit der Übersichtlichkeit überzeugt mich persönlich nicht (Bezogen nur auf das EventArgs-Beispiel). Ansonsten natürlich klar pro Trennung in einzelne Klassen.
Zudem biete das Studio mit "gehe zu" (F12) sehr gute Möglichkeiten in eine Klasse zu springen.

Du gehst aber nicht immer von einer Stelle aus, wo die Klasse schon steht, wo man mit F12 drüber gehen kann ...

Szenario: Dir fällt ein, dass Du in Klasse XYZ noch was ändern musst, machst Dein VS auf - und dann? Normalerweise weiß man, wo die Klasse ist, also in welchem Namespace. Passend dazu hangelt man sich durch, und fertig.

Das ganze hilft ja auch anderen Entwicklern, die auch auf den Code schauen - eventuell zum ersten Mal.

Ich würde die Frage umkehren: Was spart man dadurch, dass man mehrere Klassen in eine Datei zusammenfasst, bzw welche Vorteile bringt das?

Ein Problem gibt es keins, dennoch kommt es mir etwas komisch vor, für jedes EventArg eine eigene Datei anzulegen, ich meine manche haben nur eine Property und mehr nicht.

Und warum 😉?

Jede Klasse in eine eigene Datei. Auch wenn die Klasse nur drei Zeilen hat.

Der Hauptgrund hierfür ist, dass es viel leichter ist, sich zurechtzufinden, wenn die Ordner die Namespaces und die Dateien die Klassen widerspiegeln.

Wird auch in diversen Stellen empfohlen, unter anderem von Microsoft, den Codingguidelines von SharpDevelop, dem Buch "Framework Design Guidelines", ...

Wo ist das Problem, es so zu machen?

So, nachdem ich noch mal ein paar Tage darüber nachgedacht habe, und noch mal mit einigen anderen darüber diskutiert habe, habe ich heute Morgen mein Fazit geschrieben:

Siehe Dependency Injection ist keine Silberkugel

Bei SL und / oder DI geht es aber um denselben Aspekt: Instanziierung von konkreten Typen an Hand ihres Kontrakts, ohne eine Kopplung an diese konkreten Typen zu haben.
Das würde ich nicht zwangsweise so sehen:
DI erzeugt zwangsweise eine Aggregation / Komposition - ihre Aufgabe liegt also im Erzeugen und Konfigurieren von Objekten. Hierbei "gehören" die erzeugten Objekte danach auch tatsächlich zu dem Objekt (wenn auch nicht exklusiv). Sie bleiben während der gesamten Lebenszeit des Objektes mit diesem verknüpft.

Der SL hingegen löst dynamisch Objekte auf, die nicht unmittelbar mit dem erzeugenden Typ selbst verknüpft sind.
Hierbei besteht aber nicht unbedingt Zugehörigkeit zum erzeugenden Objekt - die Erzeugung bzw. Auflösung kann z.B. als Resultat eines Methodenaufrufes erfolgen - bei DI ist das nicht der Fall.

Insofern unterscheiden sich die beiden Konzepte IMHO auch von ihrer Absicht her.

Das ist ein sehr guter Punkt ... mal drüber nachdenken.

*lach* Der Vergleich mit den Hybridautos ist geil 😃

Ich versuche es, noch mal anders zu formulieren: Es gibt das Uniformitätsgesetz, was besagt, dass semantisch verschiedene Dinge sich auch in ihrer Syntax unterscheiden sollten. Im Umkehrschluss heißt das, dass man für eine Aufgabe nur einen Weg haben sollte - nicht zig verschiedene.

Das ist ja gerade etwas, worauf man bei Perl so stolz ist: http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it

In C# wurde so etwas explizit vermieden, von Anfang an. Ich finde den Link dazu jetzt nicht mehr auf die Schnelle, aber entweder Anders Heijlsberg oder Eric Gunnerson hat sich mal in der Richtung geäußert.

Und genau das macht C# auch so einfach: Es gibt Konzepte, die klar definiert sind, und für die es genau einen Weg gibt, wie sie umgesetzt werden können. Klar weicht auch C# im Lauf der Zeit auf (man denke an Delegates, anonyme Methoden und Lambdas), aber vom Prinzip her ist C# viel konsistenter und geschlossener als beispielsweise Perl.

Das finde ich gut, weil es die Sprache überschaubar und einfach macht (C# ist so schon schwer genug 😉).

Dieses Konzept zieht sich auch in das .NET Framework durch: Du hast nicht 20 Klassen für ähnliche Aufgaben, sondern es ist alles sehr ordentlich strukturiert. Nicht wie in PHP, wo es teilweise für ein- und dieselbe Aufgabe verschiedene Methoden gibt (wie beispielsweise join() und implode()).

Genau das macht auch .NET so überschaubar und einfach (in gewissem Sinne 😉).

Und genau deshalb plädiere ich dafür, auch in seinem eigenen Code nicht mehr als einen Weg für ein- und dieselbe Aufgabe zu verwenden: Wir möchten Objekte instanziieren, und zwar so, dass wir keine Abhängigkeit vom konkreten Typen haben.

Dafür gibt es zwei Lösungsansätze, die sich im wesentlichen dadurch unterscheiden, ob sie implizit oder explizit aufgerufen werden: Eben DI und SL.

SL ist flexibler, DI erspart mir als Entwickler vielleicht ein bisschen was an Tipparbeit (wobei ich das in Zeiten von IntelliSense immer nur sehr ungerne gelten lasse).

Warum sollte ich nun beide Konzepte gleichzeitig verwenden, wenn ich eines davon verwenden muss, um alle Fälle abdecken zu können? Wozu noch ein zweites Konzept, was lediglich eine "Komfortversion" des anderen ist, aber nicht so mächtig?

Das ist genau das, was mich auch am My-Namespace in VB stört: Es ist nur ein Komfortwrapper um bestehendes, kann aber nicht alles. Das heißt, obwohl es auf den ersten Blick einfacher wird, wird es auf den zweiten kompliziert, weil man es nun mit zwei APIs statt mit einer zu tun hat.

Das ist meines Erachtens ein deutlich gravierenderer Nachteil als der Vorteil, dass da ein bisschen was implizit läuft.

Wenn alles mit DI erledigt werden kann und das soweit passt, nutze ich das auch und brauche mich nicht händisch darum kümmern.

Das Schreiben der passenden Konstruktoren musst Du ebenso händisch machen wie das Holen der Instanzen per SL.

Zusätzlich kann sich der Container auch noch um den Lebenszyklus der angeforderten Instanz kümmern, ohne das ich da gross Handstände machen muss.

Funktioniert auch bei SL. Auch hier kann ich zB ein Singleton erzeugen lassen.

Ich habe kein Problem damit, zwei verschiedene Konzepte anzuwenden, wenn ich sie verstanden habe.
So als Beispiel: Du verwendest ja auch prozedurale und objektorientierte Konzepte, die sich super ergänzen, oder?

Ja - aber für verschiedene Sachen! Das ist meines Erachtens ein ganz wesentlicher Aspekt. Bei SL und / oder DI geht es aber um denselben Aspekt: Instanziierung von konkreten Typen an Hand ihres Kontrakts, ohne eine Kopplung an diese konkreten Typen zu haben.

Vergleichbar dazu wäre, wenn ich globale Variablen (prozedural) und Singleton (objektorientiert) gleichzeitig verwenden würde. Das macht aber auch niemand 😉.

@ Peter: Der Punkt ist doch aber, dass ich zwei Konzepte habe. Einmal wird ein Objekt explizit instanziiert, ein anderes Mal implizit.

Das heißt, prinzipiell gleichartiger Code sieht anders aus - mal mit, mal ohne "new". Das finde ich nicht gut, weil es unbewusst zum Nachdenken zwingt, weil man sich eben nicht darauf verlassen kann, dass es immer nach "Schema F" läuft: Statt dessen habe ich zwei "Schema F", wo mal das eine, mal das andere gilt.

Und wie gesagt - die Frage ist halt, was ich mir eigentlich mit DI so großartig spare?

Das Registrieren muss ich so oder so machen. Ob ich einen Konstruktor schreibe mit entsprechender Zuweisung oder den Aufruf des SLs an der entsprechenden Stelle einfüge, gibt sich auch nicht viel.

Was ist der Vorteil, wenn ich DI zusätzlich nehme?