www.planet-xaml.net
  •  

    ASP.NET

    ASP.NET and .NET Web Development

    • [ASP.NET, Architecture]

      Linq to SQL DataContext in a Windsor Lifestyle

      by Florian Krüsch, February 6, 2008

      Rick Strahl has a nice summary of the various options, in which scope to hold a Linq to SQL DataContext. The per request solutions is the logical choice. In the context of Domain Driven Design there might be another option, namely a DataContext per aggregate root, but this is another topic.

      A lot of code there... even though this is partly due to the fact that it attempts to work per thread or per web request in either case.

      Things get so much easier when you employ an inversion of control container. The DataContext becomes more or less an implementation detail of the repository interfaces and the per request lifecycle is just taken care of. Castle windsor and a little bit of configuration can realy help you get rid of a lot of boiler plate code here.

      XAMLcastle.configtoggle
      <configuration>
              <components>
                <component id="repositoryProvider"
                           type="Kruesch.Data.Repositories.LinqRepositoryProvider, Kruesch.Core"
                           service="Kruesch.Services.IRepositoryProvider, Kruesch.Core"
                           lifestyle="PerWebRequest"
                >
                  <parameters>
                    <connectionStringName>SiteDbConnection</connectionStringName>
                  </parameters>
                </component>
              </components>
      </      configuration>

      Be careful to dispose the DataContext at the end of the request in order to close the database connection:

      C#toggle
      public class LinqRepositoryProvider : IRepositoryProvider, IDisposable
      {
         private DomainDataContext _dc;

               // c'tor
         public LinqRepositoryProvider(String connectionStringName)
         {
             String connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;
             _dc = CreateDataContext(connectionString);
         }

         ...

               // Factory method, provice a repository implementation
         public ISharedItemsRepository GetSharedItemsRepository()
         {
             return new SharedItemsRepository(_dc);
         }

               // DON'T FORGET THIS
         public void Dispose()
              {            
                  if (_dc != null)
                  {
                      _dc.Dispose();
                      _dc = null;
                  }                        
              }
      }

      Cheers,
      Florian


      no comments
    •  ^
    • [ASP.NET]

      How to prepare for System.Web.Mvc

      by Florian Krüsch, January 23, 2008

      Read this book, learn Ruby on Rails. This is really what it is about. The names might be different (TempData instead of Flash??), but obviously the API is not polished yet.

      Second, you might want to try Monorail for the time beeing. It's a nice entry point into a whole different .NET stack that has a lot of appeal to it.

      cheers,
      Florian


      no comments
    •  ^
    • [ASP.NET, TDD]

      System.Web.Mvc

      by Florian Krüsch, October 15, 2007

      Scott Hanselmann hat die gute Nachricht schon vor ein paar Tagen verkündet, Scott Guthrie macht es jetzt offiziell: es wird ein Model-View-Controller Framework für ASP.net geben.

      Warum MVC?

      Ruby on Rails

      Der Shooting Star unter den Web-Frameworks ist elegant und überzeugt durch eine sehr saubere MVC Implementierung und integrierte Unterstützung für Unit Tests. Es ist das Lieblingsspielzeug der Agile Community. Microsoft selbst hat da im Moment nicht viel zu bieten. Klar, es gibt die Web Client Software Factory aber die ist doch um einiges schwergewichtiger und auf spezielle Enterprise-Bedürfnisse ausgerichtet.
      Mit Monorail gibt es an sich schon eine nette Adaption von RoR für ASP.net. Ein MVC Framework von Microsoft mit vollem Support als "First class citizen" in ASP.net ist aber trotzdem eine ganz andere Nummer.

      Nicht jeder mag Webforms

      Der ganze Postback/ViewState Hokuspokus in ASP.net 1/2 kann leider doch nicht zu 100% die Illusion von Statefullness erzeugen. Und wenn man Wert auf sauberes XHTML legt, sind die ID Attribute und ViewState Felder doch ziemlich störend, vor allem in Fällen in denen man sie an sich gar nicht benötigt - ein Datagrid auf das Webform gezogen und nicht aufgepasst, schon "wiegt" die HTML Seite 100k...
      Klar, man kann EnableViewState auf false setzen und die IDs irgendwie rausfiltern, aber wenn man es von Anfang an gar nicht braucht, ist das irgendwie durchs Knie ins Auge.

      Testability

      Controller lassen sich prima über Unit-Tests abklopfen. Die fehlenden Interfaces für HttpContext, HttpRequest usw. werden endlich nachgeliefert und die Abhängigkeit von System.Web an den richtigen Stellen unterbrochen.

      Bei meiner eignen Blog Engine für Planet-xaml (basierend auf Model-View-Presenter) hatte ich mich gründlich über diese Dinge geärgert, die jetzt endlich behoben werden - fehlende Interfaces z.B. für die Klassen HttpRequest/HttpResponse, um Mock Objekte für Unit-Tests zu erzeugen.

      Plugability

      Was mir an dem was ich bisher über System.Web.Mvc gehört habe gefällt ist neben dem Programmiermodell die immer wieder angesprochene offene Architektur - d.h. die Möglichkeit, eigene IoC Container oder ViewEngines einzubinden usw. Ein Monorail Clone von Microsoft wäre bei der ALT.net Crowd auch sicher nicht besonders gut angekommen.

      Da das Framework auf ASP.net basiert wird es sicherlich ohne die Unzulänglichkeiten auskommen, mit denen Rails bei aller Eleganz zu kämpfen hat (wer will schon auf C zurückgreifen, um eine Webanwendungen flott zu machen?).

      cheers
      Florian


      no comments
    •  ^
    • [MIX08, ASP.NET, Silverlight]

      Silverlight + Webservices = SilverlightWS

      by Florian Krüsch, March 5, 2008

      Although Silverlight 2.0 is yet a few hours away, some information about the API for WebService consumption are already available:

      The Silverlight WebServices blog:
      http://blogs.msdn.com/silverlightws/

      Silverlight + WebServices:
      http://code.msdn.microsoft.com/silverlightws

      This is important stuff, because Silverlight is really all about consuming data and services in a rich way within the browser.

      cheers,
      Florian


      no comments
    •  ^
     

Language | Sprache

All[e]  |  english  |  deutsch
Tags
 

Profile

Florian Kruesch

I am working as a freelance software architect, developer and consultant in Düsseldorf, Germany.

My focus is on Microsoft technologies and .NET 3.0, especially WPF, ASP.net and SQL Server.

I've been a lead programmer on the WPF development of the OTTO Vista Store at SinnerSchrader Studios.

My client list includes DHL, LG and Ogilvy Interactive.