Jeg kunne se, at der var en enkelt som havde besøgt min side, med Internet Explorer 6.

Det må vi jo sørge for at det ikke sker igen...

Læs mere

Visual Studio 2010 indeholder en fed lille funktion, som gør det muligt at deploye din web applikation.

I denne post vil jeg vise dig, hvor nemt dette er at sætte op, så du kan slippe for alt det triste deploy arbejde, som du skal lave hvis du skal deploye dit web site.

Læs mere

For lang tid siden var jeg til noget Microsoft gøjl, hvor Jakob Tikjøb Andersen snakkede om DynamicProxy. Tiden er gået, og det er nu blevet dagen, hvor jeg tænkte jeg kunne bruge dette framework til at implementere noget caching på min blog.

DynamicProxy er en dynamisk proxy generator (flot oversat, ikke?). Ved en proxy klasse menes der en klasse som har én opgave i livet, og det er at ligne en anden klasse, og så kalde den anden klasses metoder.

Et fint lille eksempel kunne være, at man gerne ville have en log over hver gang denne klasse blev kaldt, samt at den noterede hvor lang tid metoden tog. Man kunne tjekke sikkerhed, osv. - brug din fantasi :)

Forestil dig at du har en klasse som har 100 metoder. Hver metode vil du gerne gøre noget bestemt ved - evt. ændre parametrene, eller som i vores eksempel logge. Skulle du lave dette manuelt, ville du nok være doven, og kun vælge at gøre det de vigtigste steder, og du ville have noget kode som er svær at vedligeholde.

DynamicProxy er en af de værktøjer som kan hjælpe dig af med dette. Jeg valgte at skrive denne blog post, da det overraskede mig hvor let, og ligetil det er at bruge. Faktisk tog det mig vel 2min at implementere et simpelt eksempel, og det overraskede mig alligevel noget, da jeg forestille mig at der sikkert skulle store XML filer til, for at få det til at virke.

Først gik jeg ind og hentede DynamicProxy, jeg tilføjede derefter DLL filerne til mit lille test projekt, samt sørgede for at jeg havde en reference til System.Web (Umildbart så kræver DynamicProxy System.Web) Andre siger dette ikke er nødvendigt med System.Web, så hvorfor jeg lige skulle bruge den, kan jeg ikke svare på.

Jeg lavede derefter jordens mest simple interface og klasse:

public interface IDataProvider
{
    void DoStuff();
}

public class DataProvider : IDataProvider
{
    public void DoStuff() {
        Console.WriteLine("Done stuff");
    }
}

Jeg har behov for at have en klasse, som står for at lave mit logging arbejde. Dette heder i DynamicProxy for en Interceptor:

public class LogInterceptor : IInterceptor
{
    public void Intercept(IInvocation invocation) {
        Console.WriteLine("Before");
        invocation.Proceed();
        Console.WriteLine("After");
    }
}

Denne metode bliver simpelthen kaldt, hver gang en metode i mit interface bliver kaldt. Du kan se at jeg bare skriver noget ud til console, men jeg kunne nemt have gjort alt muligt fancy.

Derefter tog jeg min Main metode og skrev flg.:

class Program
{
    static void Main(string[] args) {
        ProxyGenerator p = new ProxyGenerator();
        IDataProvider provider = p.CreateInterfaceProxyWithTarget<IDataProvider>
                                      (new DataProvider(), new LogInterceptor());

        provider.DoStuff();

        Console.ReadLine();
    }
}

Det jeg gør er simpelhen at lave en ny generator, og så bede den om dynamic at lave en proxy klasse der implementere mit interface, og som har min konkrete klasse som target. Jeg kobler også min nye LogInterceptor på, og vola - så er der proxy på min DataProvider:

Before
Done stuff
After

Det var altså alt hvad der skulle til, for at lave mig en proxy klasse. Har du allerede løst koblet objekter i dit projekt, så er det altså meget let at lave en proxy, som kan fuldføre ens arbejde som alle dine metoder skal udføre.

Mulighederne er mange, og jeg har bare vist jer jordens mest simple eksempel.

Læs mere

Jeg er lidt i et dilema. Jeg elsker både VB.NET og C#.

Når jeg skal lave et nyt projekt, så sidder jeg altid og bruger alt for lang tid på at spekulere i hvilket sprog, jeg skal lave mit program i. Vi er alle enige om at det på et højt plan er rimelig ligegyldigt, da VB.NET og C# på et feature plan, er så ens, at der næsten ikke er forskelle - og dog.

Jeg elsker mit VB.NET, jeg er ikke flov over at sige det, selvom jeg godt ved at C# programøres generalisering af en VB.NET programmør, er at han er en anden-rangs programmør, som ikke har lært sine simikolons, og skriver dårlig kode. 

Så lad mig som det første slå det fast: Jo jeg skriver dårlig kode - men det gør jeg også i C# - sproget har intet med det at gøre  :)

Hvis jeg kigger på sprogene side om side, så har jeg meget svært ved at argumentere for at bruge C#, andet end den Geek love der følger med. Hvis jeg laver et VB.NET projekt, så er jeg noget mere alene, end hvis jeg f.eks. lavede det i C#. Jeg kan lige forestille mig den ”addr” føelse, som C# programmørene får, når de finder ud af at projektet er VB.NET.

Men sådan er .NET kulturen, og det er nok ikke noget man kan gøre noget ved.

Grunden til at jeg er så glad for VB.NET er at jeg ser C# som et meget kræsent sprog. Et eksempel er at du skal Caste dine objekter til strings eller til andre sjove objekter, hvilket resultere i en masse tekst, for at fortælle compileren, at du ved hvad du gør. I VB.NET stoler compileren på dig, som standard, og lader dig caste ting til andre typer, uden at du skal til at caste. Du har også muligheden for at sætte såkaldt Strict på, hvilket betyder at den nu også hyler, når du gør den mindste ting, som kunne resultere i fejl, som er sket ved casting. Du har altså valget.

Nu skal det siges, at jeg har oplevet, at vi har fået en enkelt fejl, i forbindelse med implicit casting i VB.NET, i det år, jeg har arbejdet med VB.NET på arbejdet. Hvis man tager den tid, det tog at finde den fejl (10min), og så opvejer det med den tid jeg har sparet, ved ikke at skulle caste hele tiden, så tror jeg nok jeg har vundet nogle dage på den der. Casting er en produktivitets dræber – puntum.

VB.NET har også en masse fede features, som XML literals, og My namespacet, som er fyldt med goodies. Vi har With keywordet, som gør at vi kan tilgå et objekt nemt, hvis vi bruger det mange gange. Select Case (switch) er faktisk brugbart i VB.Net, hvor i C# er den meget mere begrænset. En anden ting, som er lidt sjov i forbindelse med extensionmethods er at VB.Net også har noget som heder Modules. Modules, giver dig lige præcis mulighed for at have extenionmethods, som du kan kalde, uden at de ligger på et objekt, da de bare er globale metoder, alt efter hvilket namespace du inkludere. Derfor kan du lave små metoder, som gør din kode mere præcis – pas dog på med at du lige pludselig ikke gør din kode ikke-testbar. (Det samme gælder med extenionmetodes, og generelt statiske ting)

Modules er dog ikke noget, som jeg generelt bruger så meget, men det er en sjov lille ting i VB.NET, som kan have sin plads, og måske erstatte den typiske Utils klasse, med hjælpemetoder.

Generelt, vil jeg faktisk beskrive VB.NET, som mere Ruby agtigt, end C#. Det giver nogle fede features, som er koblet op mod produktivitet, istedet for ”korrekthed”.

Grunden til jeg elsker C# er dog lidt anderledes. Det er nemlig ikke pga. sproget, men mere de tools, som understøtter det. Resharper er et godt eksempel, som ganske hvist også virker 10% til VB.NET, men det er bare så meget bedre i C#. 

Kodeeksempler er generelt også i C# - så man skal til at konvere koden til VB.NET – hvilket er ganske let, men dog en irretation aligevel.

Til sidst, så er det, lige som med meget andet, bare så meget lettere at følge med strømmen, og bruge det som alle hylder – så slipper man for alle diskutionerne om hvorfor man dog ikke brugte C#.

Jeg er stadig i tvilv om hvad jeg skal bruge, men sådan er det med valg – jeg er bare dårlig til sådan noget. 

 

Nå men, hvad siger jakob?

Læs mere

Jeg var til et Microsoft event her i lørdags hvor vi hørte Scott Hanselman snakke om ASP.NET MVC. Det meste af det han snakkede var noget jeg kendte i forvejen, men han viste en rigtig fed ting, som de har lavet til MVC.

Scott viste en T4 template, som du bare river ind i dit MVC projekt. Denne T4 template går så ind og kigger på dit projekt, og laver statiske klasser til alle dine billeder, views, controllers osv. På denne måde får du “semi-strongly-typed” links til filer, views osv.

Hvis du f.eks. fjerne eller omdøber en image fil i dit projekt, vil T4 templaten omdøbe det statiske felt, og du vil på den måde ikke kunne kompile – det er da genialt.

Scott viste kun ganske hurtigt hvad denne T4 template kunne, men jeg kan kun anbefale at tage et kig på den. Det er meget let at sætte op. Du kan hente T4 templaten her

Bemærk at du nok ønsker at compile dine MVC views, for at få maksimalt udbytte af denne template.

Læs mere