Simple reads with Entity Framework

Posted on March 3, 2011 by

This works nicely for quick reads.  Requires no mappings or any of that junk. Just a DataReader shaped to a type.

Edit: Because this is my first day to ever work with EF, my first attempt at this was more complicated (you can see this evolution at the gist).  After removing my useless code, you can see it’s just Entity Framework.  Sadly I can’t take any credit.  Still – this IS cool.  Fast, super easy, typed queries with only framework dependencies.  I was surprised to see it supported the mapping-less projections.  Perfect for all of those fancy persistent view model scenarios all the cool CQRS kids are doing.

using System;
using System.Collections.Generic;
using System.Data.Entity;

public static class Effin
{
    public static IEnumerable<T> Query<T>
        (this string connectionStringName, string sql,
        params object[] parameters)
    {
        return new DbContext(connectionStringName)
            .Database.SqlQuery<T>(sql, parameters);
    }
}

public class Example
{
    public void UsingEffin()
    {
        IEnumerable<Name> names =
            "data".Query<Name>("select FirstName from Person");

        foreach (var name in names)
        {
            Console.WriteLine(name.FirstName);
        }
    }

    public class Name
    {
        public string FirstName { get; set; }
    }
}
Posted in Tools | 1 Comment

Reuse is overrated, then came package management

Posted on February 27, 2011 by

Reuse is overrated. 

True story: a team building a system.  They decide that one chunk of code might be valuable in another project or two.  So they extract it into a library and open source it.

Project complete, team reorganizes and begins a couple new projects.  Both new projects depend on that library.  For awhile everything is great.

Sooner or later someone needs to make a change.  It’s sort of a pain, because the source code is in another IDE configuration.  Actually it’s been awhile since anyone worked on it and it’s hard to find a developer on the team who has that version of the IDE installed.  But the change happens, painful as it may be, because it has to.

Someone later gets lazy.  They build it locally and copy the assemblies directly into the lib folder.  Now the library was compiled from source code that’s not in the version control system.  This is spinning out of control.  Or maybe that was intentional – because the other team is using the library too, but they have different needs and we’ve sort of been in a mutually-assured-destruction paralysis about what changes to make.

Eventually someone realizes the solution is not to depend on this library, the compiled bits, but to just copy the source code over.  We need to make our tweaks, they need to make their tweaks.  It makes sense.   So we lose our code reuse; does anyone care? 

This dirty-feeling code copying can be a good idea for a non-technical reason:  it emphasizes that the important element of reuse is the human expertise to understand, create, use and modify a solution that solves a particular problem.

Turns out NuGet is great for this.  I noticed that Rob Conery packaged his Massive library as just a file.  A source code file.  Not a .dll.  Great idea, and I immediately thought of all the code that I want to share among many projects but also have the flexibility to change, now – without context switching or fear of repercussions.

You just put the files in a Content subdirectory and the NuGet process will shove them in the project root or App_Code or wherever.

I did the same with a little utility class that we use a lot, and I’m going to do it some more. 

For many teams, a hosted NuGet feed with content files is the new helper library.

Posted in Agile, Tools | 6 Comments

Type systems and their advantages

Posted on December 2, 2010 by

Typing is not the bottleneck.  Neither is typing.

If you’ve been a programmer sometime in the last fourteen billion years you’ve noticed that there’s this conversation about type systems, specifically about comparing static type systems to dynamic type systems.

Dynamic typing doesn’t mean you can change the type of a thing (even though you sometimes can) it means you can change the shape of types themselves at run time.  It means that you can tell a variable to write itself some new, strange, dynamic behavior, but you don’t tell it what to write, you tell it how to decide what to write.  And you can eliminate a lot of duplication this way.

But static type systems don’t give you that ability.  You have to define the shape and behavior of a type at compile time.

I know what you’re thinking: that really stinks!  I want the ability to muck about with my variables, and have them run my code against their own internals and have them write new methods for themselves, and decide how they handle calls against methods that don’t exist, and even crazier things.

The static type system folks can do something that’s really powerful.  They can use the type system itself as a global registry.

You see this in a lot of the C# written today, especially the stuff that makes heavy use of an IOC tool and generics.  They’ll ask the system to get all the types that implement some interface, or for the types that close some interface and another type.  Then they take these types and instantiate one instance of each of them, and use those instances in some way.  Each instance runs in a chain or pipeline, or to apply a series of filtering functions to a data set.

The type system becomes a big dispatch table, with type names as global keys, but it’s more like a dispatch tree, because of polymorphism and generic type parameters and all that.

It’s freakin’ cool, once you start doing it – it’s elegant and easy compared to the old stodgy way of programming.  And the IOC tools they use keep getting more interesting features that let them query the type-system-as-dispatch-tree in novel ways.

The dynamic type system folks will shrug and suggest implementing dispatch table with a hash like they’ve been doing in Perl for 15 years.

The static type system folks keep losing because their arguments are bad – Compile Time Checking and Tooling just aren’t cutting it.  But they may be onto something if they could articulate the benefits of this global registry better than I can.

Posted in Deep thoughts | 8 Comments