zunächst einmal: Good Code!

Da sieht man mal, wie wichtig es ist, gute Kommentare zu schreiben und diese auch richtig zu lesen. Fakt ist, das Du mit der “Synchronisation” von HttpRequest.Cookies und HttpResponse.Cookies recht hast – sie werden nicht synchronisiert. Allerdings scheint es mir hast Du den Kommentar falsch interpretiert – es geht nicht um die Erstellung eines neuen Cookies, sondern um die Modifikation.

Doch auch bei der Modifikation muss ich Dir natürlich recht geben – immer über HttpResponse.Cookies gehen! Ich behaupte jedoch weiterhin, das der gezeigte Code richtig ist. Wie kommt’s?

Tja, gerade das, was Du im Kommentar kritisierst ist wohl der entscheidende Hint: die Methode heisst “ResetSessionCookieDomain”. Soll heissen, die Methode setzt den Domain-Wert des Session-Cookies zurück. Man beachte auch, das der gesamte Code wie erwähnt in einem HttpModule abläuft. Die einzige wichtige Info, die ich nicht mitgegeben habe ist, das die Methode effektiv aufgerufen wird, nachdem der SessionState von der HttpRuntime erzeugt wurde (siehe AquireRequestState / ReleaseRequestState). **In genau diesem Kontext** ist es korrekt, den Session-Cookie über HttpRequest.Cookies zu verändern. Genau genommen ist sogar der Kommentar **in genau diesem Kontext** richtig – obwohl er wirklich irreführend ist.

Denn genau auf die selbe (richtige) Art und Weise, wie Du in Deinem refaktorisierten Code machst, setzt intern der SessionStateManager bzw. der SessionIDManager das Cookie-Handling um. Es nimmt also als Ausgangsbasis HttpRequest.Cookies und modifiziert es später über HttpResponse.Cookies. Möchte man nun den Session-Cookie selbst noch modifizieren, so bleibt einem nichts anderes übrig, als das über HttpRequest.Cookies zu tun – schließlich möchte man verhindern, das die internen Modifikationen von ASP.NET ausgelassen werden. Am Ende der ASP.NET Pipeline (genauer: zu ReleaseRequestState), wird dann der Cookie über HttpResonse.Cookies intern aktualisiert.

Des Weiteren finde ich die Argumentation, das ein Methodenname die Parameter der Methode reflektieren soll nicht gerade erstrebenswert. Würde man dies stringent umsetzen, hätte man schnell zum Einen ellenlange Methodennamen und zum Anderen würde man den Fokus von dem eigentlichen Zweck – dem “was macht die Methode” – ablenken und abweichen.

Die refaktorisierte Variante von Dir ist sehr schlüssig und übersichtlich. Die Fragestellung für mich ist es nun, welcher der zwei Code-Varianten lesbarer und übersichtlicher ist. Ich persönlich tendiere immer noch zu meinem gezeigten Beispiel – obwohl Deines, wie Du schon richtig anmerkst, eine bessere Separation of Concerns gewährleistet. Entscheidend ist für mich der Kosten/Nutzen-Effekt. Deine Variante ist in Relation zum Aufwand, den Du betreiben musstest, nicht sondernlich lesbarer oder einfacher – obwohl in objektorientiertem Sinne formal korrekter.

Bei der Entscheidung zur Refaktorisierung sollte man meiner Meinung mach nicht nur den Aspekt der Korrektheit in betracht ziehen, sondern andere Faktoren wie Einfachheit, Isolationsgrad und Chattiness beachten. Nichtsdestotrotz – ich finde Deine Variante äußerst elegant – wenngleich nicht lesbarer oder einfacher. Gerade Deine Refaktorisierungsbemühungen bestätigen meine Behauptung, das Kommentare per se kein Code Smell sind. Im Bestreben, den Kommentar überflüssig zu machen, hast Du meiner Meinung nach die Komplexität erhöht und die Lesbarkeit gemindert.

Dennoch gebe ich zu, das auch mein gezeigter Code (und der Kommentar) nicht gerade gelungen ist. Der Kommentar enthält die Falschaussage “always synchronized” – das ist schon mal ein dicker Minuspunkt. Es ist besser, einen Kommentar ganz wegzulassen, anstatt einen falschen Kommentar zu schreiben – Shame on me!

Des Weiteren würde ich an dem ersten Code-Beispiel die mangelnde Konvention in der Benennung der Methoden anmahnen. Während die Methode selbst “ResetSessionCookieDomain” heisst (IMHO korrekterweise), ist der Name der Methode zum Ermitteln des Cookienamens “GetApplicationCookieName” – aus meiner Sicht sollte das wohl eher zu “GetSessionCookieName” umbenannt werden.

Am liebsten würde ich jetzt das Code-Beispiel im Post korrigieren – ich lasse es dennoch so falsch wie es ist stehen, damit man auch unsere Kommentierungen nachvollziehen kann.

Gruß,
Ilker

der Kommentar in Deinem Codebeispiel ist so entweder von mir falsch verstanden worden, oder sagt etwas aus, was nicht korrekt ist. Die Cookie Collections in Request und Response sind nicht synchronisiert. Ganz im Gegenteil. Der Unterschied zwischen den beiden Collections ist, dass im Request alle vom Client geschickte Cookies, plus transidiente Cookies vorgehalten werden und in Response ausschließlich neue Cookies vorgehalten werden, die im Response im Set-Cookie Header mitgesendet werden. Korrekt ist allerdings, dass Cookies, die über Response.Cookies.Add gesetzt werden anschließend zusätzlich in Request.Cookies auftauchen. Um den Unterschied noch weiter zu verdeutlichen: Cookies, die über Request.Cookies.Add hinzugefügt werden, sind sogenannte transidiente Cookies – das heißt, sie stehen der restlichen Verarbeitungskette zur Verfügung – werden allerdings anschließend NICHT an den Client gesendet. Man kann das verifizieren, indem man Request.Cookies.Add aufruft und dabei beobachten kann, dass Response.Cookies.AllKeys keine neuen Keys enthält.

Zusätzlich finde ich, dass Dein Codebeispiel gerade ein ideales Beispiel dafür ist, dass man hellhörig (= potential Code Smell) werden muss, wenn man das Bedürfnis hat einen Kommentar zu schreiben.

Ich sehe da durchaus Verbesserungspotential. Denn zum Beispiel passt die Methodensignatur nicht zum Methodennamen. Es ist im Methodennamen von Cookies die Rede – es wird allerdings eine HttpApplication übergeben. Das passt nicht zusammen. Zusätzlich wird in der Methode auf IsNewSession geprüft – davon steht ebenfalls nichts im Methodenname.

Ich hätte Dein Codebeispiel wie folgt refactored (ich hoffe mal, dass das formatiert bleibt):

private void SetApplicationCookieDomainOnNewSession(HttpApplication application)
{
  string host = application.Request.Url.Host;
  if (application.Session.IsNewSession && !application.Request.Url.IsLoopback)
  {
    CookieHandler cookieHandler = new CookieHandler(application);

    HttpCookie appCookie;
    if (cookieHandler.TryGetExistingCookie(this.GetApplicationCookieName(), out appCookie))
    {
      appCookie.Domain = this.GetCookieDomain();
    }
  }
}

public class CookieHandler
{
  public CookieHandler(HttpApplication application)
  {
    Application = application;
  }

  public HttpApplication Application { get; private set; }

  ///
  /// Tries to retrieve an existing cookie.
  ///
  /// The name of the cookie to get
  /// The cookie, if  is true, otherwise null
  /// True if a cookie was found, otherwise false.
  public bool TryGetExistingCookie(string cookieName, out HttpCookie appCookie)
  {
    try
    {
      HttpCookie cookie = Application.Request.Cookies[cookieName];
      if (cookie != null)
      {
        appCookie = cookie;
        return true;
      }
    }
    catch (Exception ex)
    {
      LOG.LogException(ex);
    }

    appCookie = null;
    return false;
  }
}

Bessere SoC. Man beachte auch, dass ich wenn es um Dokumentationskommentare geht absolut für Kommentare bin (Intellisense, API Doku, …)

Trotzdem kann ich erstmal nur zustimmen: When you feel the need to write an (inline) comment, first try to refactor the code so that any comment becomes superfluous.

Denn das Refactoring hat zumindest in meinen Augen den inline(!) Kommentar ersetzt. Und wenn wir jetzt auch noch 3.5 einsetzen, dann können wir es noch sprechender gestalten:

public void DieAufrufendeMethode(HttpApplication application)
{
  ExecuteOnIsNewSessionSafe(application,
    () =>
    {
      CookieHandler cookieHandler = new CookieHandler(application);
      ResetApplicationCookieDomain(cookieHandler);
    }
    );
}

private void ResetApplicationCookieDomain(CookieHandler cookieHandler)
{
  HttpCookie appCookie;
  if (cookieHandler.TryGetExistingCookie(this.GetApplicationCookieName(), out appCookie))
  {
    appCookie.Domain = this.GetCookieDomain();
  }
}

private void ExecuteOnIsNewSessionSafe(HttpApplication application, Action action)
{
  if (application.Session.IsNewSession && !application.Request.Url.IsLoopback)
  {
    action();
  }
}

Dann ist endlich das HttpApplication aus der Methodensignatur draußen. (DieAufrufendeMethode ist dabei die Methode wo vorher ResetSessionCookieDomain(HttpApplication application) aufgerufen wurde.)

Viele Grüße,
Tobi