ORM and C#3 anonymous types

Here goes my first blog post in 1+ years.

Nowadays I’m playing around with VS 2008 trying to abuse all the new features as much as possible.

Earlier today I was talking to Mats Helander about making a NPersist v3, for .NET 3.5.
We were discussing new features such as supporting anonymous types instead of our old “Tabular” concept.

After a while I started to think about the possibilities to use anonymous types to create read only views for stored procs,
and I came up with a quite slick solution ( in my own opinion OFC ;-) )

Anyway, here is what I came up with:

//create a prototype for our result 
var prototype = new { FirstName = "" , Age = 0 , Email = "" };      

//fill a list with items of the above type with data from an sproc 
var res = MyDal.ExecuteStoredProc(prototype, "sp_MyStoredProc", p1, p2, p3);      

//present the data in our top notch UI 
foreach (var item in res) 
{ 
    Console.WriteLine("FirstName = {0}", item.FirstName); 
}

What I do here is:
I create an object of an anonymous type, which will act as a prototype for our result.
The anonymous type contains our properties and the type for each property.

Then I pass the prototype object into my DAL and ask my DAL to execute an stored procedure with some args.
The DAL executes procedure and fill a generic list of my anonymous type with the result.
And then return the filled list the consumer.

This allows the consumer to call a stored procedure and get the result in an objectified way.
Making it possible to work with his data in a typed way w/o adding typed datasets or entity classes.
OK, the anonymous type is a sort of entity class too.
But since it can be designed per use case, you do not have to clutter the project with loads of view specific classes.

Well that’s it for now.
Full sample code will be provided soon.

//Roger

2 thoughts on “ORM and C#3 anonymous types”

  1. But on the other hand, the anonymous type definition is for all intents and purposes useless outside of the class in which it was defined. As soon as you return it up to a layer above where it was defined, in order to use it, the client has to resort to all sorts of bizarre (and rather slow) reflection-based trickery that ends up tying them to property names as strings that could have just been used for keys to a dictionary in the first place.

    Anonymous types are great for use in the middle of a bunch of LINQ mangling, but I’m just not sold on the reams and reams of “anonymous types as dictionaries” posts that have been cropping up in recent times. When it comes to shifting semi-structured data around, I’ll be sticking to dictionaries (of items and collections (of items and collections and…) and dictionaries (of items and collections and…) …)

  2. Yes, I completely agree with you, this is by no means a way to read data and pass it around your enterprise application.

    For such scenarios I would still use an real entities or DTO objects.

    But for small tool apps where you simply want to fetch readonly data and display it on a webpage or console window, this could be pretty useful.

    >>useless outside of the class in which it was defined
    And that is pretty much the point of this post, in this case it is the consumer that is defining it, and passing it as a prototype to the DAL.
    Thus, the consumer is aware of the definition and can use the typed nature of the anonymous type.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s