If you’re like me (and apparently many other people), when you start using (no pun intended) WCF by creating a client channel, it’s only a matter of time before you realize that you’re probably doing it wrong. 

Problem number one is that if you don’t explicitly close the connection, it’s only a matter of time before the connection starts faulting.  So you say to yourself, “Aha!  I need to close the damn connection.  And since I’m a good .Net programmer, I see the IChannelListener interface extends the IDisposable interface so I can just wrap my call in a ‘using’ statement which will explicitly clean up all my resources no matter what happens during the method execution.”

And then an exception happens.  Even though you wrap your call in the using statement, you see this weird exception about the channel being in the faulted state (or something like that).  Wait – I wrapped my call in the using statement.  This should work!  So you fire up Google Bing and quickly learn the WCF team made the decision to implement IDisposable wrong uniquely. 

In order to get a WCF client to work as expected, you need to workaround the decision made by the WCF team and wrap all your WCF calls in blocks similar to this one:

  1: var channelFactory = new ChannelFactory(binding, endpointAddress);
  2: 
  3: var proxy = channelFactory.CreateChannel<ICustomerService>();
  4: IClientChannel clientChannel = (IClientChannel)proxy;
  5: bool isSuccessful = false;
  6: try
  7: {
  8:   proxy.AddCustomer(customer);
  9:   clientChannel.Close();
 10:   isSuccessful = true;
 11: }
 12: finally
 13: {
 14:   if ( !isSuccessful )
 15:   {
 16:     clientChannel.Abort();
 17:   }
 18: }

As you can see here, you must explicitly call Close() on the client channel unless an Exception is thrown, in which case you need to call the Abort() method.

This code doesn’t just emit a code smell of violating the DRY principle, it absolutely reeks of it.  Steve Smith (and others) have come up with extension/utility methods aimed at simplifying the call and removing the repetitive boiler plate code from the above example.  Inspired by these solutions, I’d thought I’d throw out my own answer to this problem:

  1: public class WcfClient<TInterface>
  2: {
  3:   public WcfClient(Uri uri) : this(uri, new NetTcpBinding(SecurityMode.None))
  4:   {
  5:     Uri = uri;
  6:   }
  7:   
  8:   public WcfClient(Uri uri, Binding binding) 
  9:   {
 10:     this.Uri = uri;
 11:     this.Binding = binding;
 12:   }
 13:   
 14:   public Uri Uri
 15:   {
 16:     get;
 17:     private set;
 18:   }
 19:   
 20:   public Binding Binding 
 21:   {
 22:     get
 23:     private set;
 24:   }
 25: 
 26:   public void Using(Action<TInterface> serviceAction)
 27:   {
 28:     TInterface proxy = CreateChannelFactory().CreateChannel();
 29:     IClientChannel clientChannel = (IClientChannel)proxy;
 30:     bool isSuccessful = false;
 31:     try
 32:     {
 33:       serviceAction(proxy);
 34:       clientChannel.Close();
 35:       isSuccessful = true;
 36:     }
 37:     finally
 38:     {
 39:       if ( !isSuccessful )
 40:       {
 41:         clientChannel.Abort();
 42:       }
 43:     }
 44:   }
 45: 
 46:   public TResult Using<TResult>(Func<TInterface, TResult> serviceAction)
 47:   {
 48:     TResult result;
 49:     TInterface proxy = CreateChannelFactory().CreateChannel();
 50:     IClientChannel clientChannel = (IClientChannel)proxy;
 51:     bool isSuccessful = false;
 52:     try
 53:     {
 54:       result = serviceAction(proxy);
 55:       clientChannel.Close();
 56:       isSuccessful = true;
 57:     }
 58:     finally
 59:     {
 60:       if ( !isSuccessful )
 61:       {
 62:         clientChannel.Abort();
 63:       }
 64:     }
 65: 
 66:     return result;
 67:   }
 68:   
 69:   private ChannelFactory CreateChannelFactory()
 70:   {
 71:     var endpoint = new EndpointAddress(Uri);
 72:     return new ChannelFactory(Binding, endpoint);
 73:   }
 74: }

The two Using() methods offer an overloaded way to invoke a method on the service proxy.  In the first version, you can invoke an Action call which doesn’t expect a returned value.  In the second version, the TResult generic type determines the type of value expected from the invocation of the proxy object.  The return value will flow through from the proxy call execution to the caller.  Think of these two methods as being akin to the differences between a Sub or a Function in VB (my God, did I just admit to knowing VB?!?!?!).

The WcfClient code is responsible for creating the client proxy and returns the proxy back to the calling code.  As the caller, here is how you would execute the methods:

  1: string wcfUri = ConfigurationManager.AppSettings["wcfUri"];
  2: 
  3: var wcfClient = new WcfClient<ICustomerService>(wcfUri);
  4: 
  5: wcfClient.Using(proxy => proxy.AddCustomer(new Customer()));
  6: 
  7: // ...
  8: 
  9: Customer[] customers = wcfClient.Using(proxy => proxy.GetCustomers());

The nice thing about this solution is that we take care of the exception handling and correctly clean up our resources in one place, and that logic is completely shielded from the calling code.  Plus, we can account for situations where a return value is expected versus when one is not.

Tuesday, June 09, 2009 11:02:10 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C# | WCF

When I first jumped into C# programming, one of the biggest points of confusion for me was in understanding delegates.  You see, Java had no real similar concept.  So the idea of function pointers didn’t really register with me.  I saw some really weird syntax for event handlers that looked like this:

   1: myButton.Clicked += MyButton_Clicked;

   2:  

   3: // ...

   4:  

   5: private MyButton_Clicked(object sender, EventArgs e) 

   6: {

   7:     // do something

   8: }

Eventually, I caught on that because the function called MyButton_Clicked satisfied the signature required by the OnClick event, it could be added as an event handler to the event.

Aha!  Delegates are nothing more than “interfaces” at the method (as opposed to class) level.  So even though I understood what delegates were, I still didn’t see a widespread use for them outside event handlers.  Sure, I saw examples where they were used, but they all seemed very contrived to me. 

Enter in lambda expressions

Lambda expressions were introduced in C# 3.0.  I’ve said it before, while lambda expressions are new to .Net, they are not even close to being a new concept in programming languages.  They have been around forever.  Basically, it’s a terse syntax for defining anonymous delegates.  In .Net, they were really a simpler way to interact with LINQ.  Now you no longer had to go through the ceremony of creating an explicit method just to satisfy the compiler.  This “inline” function call was especially useful in simple delegate calls, as in a Predicate:

   1: var myList = new List<Person>();

   2: // ...

   3: Person chris = myList.Find(person => person.FirstName == "Chris");

I don’t know why, but I really latched on to lambda expressions in a  way I never did with delegates.  Which is actually a little weird, since I’ve heard numerous complaints that the lambda expression syntax is too confusing for the average developer. 

Changing the way I code

Now, lambda expressions have really changed the way I approach programming.  I’ll give an example from Miado.  I wanted to add support to Miado for creating typed DataSet objects (in addition to regular DataSet objects).  I added support for a querying for a DataSet using generics, where the generic type had to be a class derived from DataSet:

   1: public virtual T QueryForDataSet<T>() where T : DataSet

I wanted to have one common method that handles creating both types of DataSets (the ol’ DRY – i.e. “Don’t Repeat Yourself”).  Here’s the rub - when using a DataAdapter to fill the DataSet, the method actually is just a little different from using a regular DataSet versus a typed one.  It’s not that different, but enough to make you have to handle it two different ways.  Previously, I probably would’ve created a template method or maybe handled it through an interface.  But to use interfaces would require an interface to define the method and two separate classes to implement the varying implementations.  That’s a lot of work to accomplish this seemingly simple task.

Hmm … if I could just pass in the method  that I want to call, I can solve this problem much easier.  Enter in my good friend Action<T> to the rescue! 

Action<T>

Action<T> is a delegate method.  It takes in an instance of the generic T type defined in its signature and has no return value.  So it’s a callback method that performs some action (and thus cleverly named).  I love this delegate.  It’s really great for implementing simple one line functions via a lambda expression.  The syntax becomes very terse without having to build up all the ceremony just to satisfy the compiler.

Implementation

Actually, Action is overloaded so you can pass in multiple arguments.  In my case, I am using two arguments to the method (i.e. Action<T,U>).  Here is the way I implemented it:

   1: private T QueryForDataSetUsingCustomDataAdapterFillFunction<T>(

   2:             Action<DbDataAdapter, T> adapterFillFunction) where T : DataSet

   3: {

   4:     T ds = CreateEmptyDataSet<T>();

   5:  

   6:     using ( DbConnection conn = this.Database.CreateConnection() )

   7:     {

   8:         conn.Open();

   9:  

  10:         using ( DbCommand cmd = conn.CreateCommand() )

  11:         {

  12:             cmd.CommandText = this.CommandText;

  13:             cmd.CommandType = this.CommandType;

  14:  

  15:             if ( this.Parameters != null )

  16:             {

  17:                 cmd.Parameters.AddEnumeration(this.Parameters);

  18:             }

  19:  

  20:             using ( DbDataAdapter adapter = this.Database.CreateDataAdapter() )

  21:             {

  22:                 adapter.SelectCommand = cmd;

  23:                 adapterFillFunction(adapter, ds);

  24:             }

  25:         }

  26:     }

  27:  

  28:     return ds;

  29: }

  30:  

  31: public virtual DataSet QueryForDataSet()

  32: {

  33:     return QueryForDataSetUsingCustomDataAdapterFillFunction<DataSet>(

  34:             (adapter, ds) => adapter.Fill(ds));

  35: }

  36:  

  37: public virtual T QueryForDataSet<T>() where T : DataSet

  38: {

  39:     return QueryForDataSetUsingCustomDataAdapterFillFunction<T>(

  40:             (adapter, ds) => adapter.Fill(ds, ds.Tables[0].TableName));

  41: }

Basically, I made it so that the common method takes in a function that, given a DataAdapter and a DataSet, does some work on those objects.  So the two public methods pass in a different implementation of the Fill() method on the DataAdapter.  Like I said before, it’s kind of like using interfaces for methods.  The common method (in line 23) calls the Action method to perform its specific function by passing back the current DataAdapter and DataSet.

Conclusion

Again, lambda expressions have changed the way I approach programming.  Once you get a handle on the syntax, it’s a great tool to have in your toolbox!

Sunday, February 01, 2009 3:46:49 PM (Eastern Standard Time, UTC-05:00)      Comments [1]  .Net | C# | Miado

There is a great book on the Java programming language called Effective Java by Joshua Bloch.  Even if you don’t use Java as your primary coding language, this book contains innumerable software engineering tips and design patterns that will help you improve in no matter what language you code.  It’s a great reference guide that I continuously go back to, even though I haven’t done much Java coding in the last few years.  The fact that I bought the second edition when it came out despite the fact I no longer really do Java should tell you something.  Josh, if you’re reading this post, you can contact me to see how you can send me the referral fees.

The first item in the “Classes And Interfaces” section of the book is: “Minimize the accessibility of classes and interfaces”. The idea is to not just think of encapsulation in terms of class internals, but to also take it to the next level - meaning up to your API in general.  As Bloch says,

"The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.  A well-designed module hides all of its implementation details, cleanly separating its API from its implementation.  Modules then communicate only through their APIs and are oblivious to each others’ inner workings."

It’s a principle I strive for in all my software design.  By making your API strong and weakening your implementations, you are effectively decoupling your module from the rest of the system.  This decoupling allows you to easily develop, test, and refactor your module in isolation without affecting the rest of the system.  It’s a concept that falls right in line with “The Open/Closed Principle”.  This principal states you should make your software modules “open” for extension, but “closed” for modification.

One of the easiest ways to accomplish encapsulation in an object-oriented language is through the use of access modifiers (e.g. public, protected, internal, private).  Anything you declare as public is open to the whole world.  Therefore, Bloch says that when design your software, “make each class or member as inaccessible as possible.”

I am the author of an open-source project called Miado.  It’s an API that sits on top of ADO.Net and attempts to simplify data access and remove the repetitive, error-prone, boiler plate code we write over and over again in our data access modules.  In building my API, I’ve tried to adhere to good OO design principles.  I’m a big fan of coding to interfaces, using dependency injection, unit testing, and mocking.  Therefore, I’ve exposed most of the API as interfaces rather than concrete classes.  Since I want to abide by the tenants I’ve talked about already, I’ve restricted the corresponding class implementations of these interfaces.  They are declared as “internal”, which in C# terms means they are only exposed to classes in the same assembly in which they are defined.  Since no external assembly can reference my implementations, the “black box” of my interface is upheld, yet allows the consumer to override their own implementations (even if it is only in a mock).

Now this is all well and good, but there’s one more thing of which you need to be aware.  Remember that when you mark a class as “internal” in C#, only classes in that same assembly can reference that class.  Like I said, I’m a big fan of unit testing.  How do you test a class in a test assembly when you can’t even see it???  You could move your test classes to the declaring class assembly, but that’s really just a bad idea.  It adds extra overhead to an assembly and provides no real value to its consumer.  It’s just extra noise taking up space.  And jumping through hoops to remove those test classes as part of a build step reeks of wasted effort.

Java has a nice way to get around this gotcha.  In Java, “protected” scope is somewhat similar to “internal” scope in C#, with one important distinction.  Protected accessibility in Java allows any subclass to access that member, as well as any other class in the same “package” (a close cousin to a “namespace” in C#).  So when you write your unit tests in Java, you merely have to declare your unit test class as belonging to the same package as the class being tested, which then allows you to access any of that class’s internal state and behavior, even if it gets deployed as a separate jar file.  Unfortunately, C# has no similar “namespace” accessibility modifier.

But .Net does have some aces up its sleeve.  There is a way to declare another assembly as a sort of “friend” assembly so that it can see the original’s internal members.  In the original assembly (the one being tested), add the following line to your AssemblyInfo.cs class:

   1:  // let the unit tests see internals of this assembly

   2:  [assembly: InternalsVisibleTo("Miado.Test")]

Monday, January 12, 2009 4:46:33 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C# | Java | Miado

In my last post, I showed how to write stuff out to a temporary directory.  After I wrote the post, I started thinking about how people could misconstrue the meaning of it.  The post was intended to show how to dump stuff easily to a random directory on the file system.  The code that drove me to write that particular example came from a unit test that was using the temporary directory as a repository for the output of the XmlSerializer.  In other words, I really was not doing anything meaningful with the data.

To clear things up, I thought I would write a post that showed how use a unknown storage directory as a meaningful repository for application data.  What constitutes meaningful data?  I don't know, it's your app!!!  But common possibilities include application settings, user-specific data, etc...  I'm thinking of things that might be otherwise be stored in the registry.  Yeah, don't do that anymore.  I don't know about you, but the just the word "registry" causes me to shudder.

.Net has introduced a new concept called "Isolated Storage" to hold this type of information.  Isolated storage is an unspecified location on the file system that is hidden away from the application.  Even though the location is unknown, the application is guaranteed to have full permissions to it, even if it is running in a restricted security mode.  As it name implies, the location is "isolated" so that any data written to it does not affect other applications or anything else on the file system.  So as far as security goes, you're limited to only hurting yourself by maliciously or ignorantly (mis)using this repository.

Here's a code sample of how you would use it to store data:

// get the location specific to this user/assembly
IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForAssembly();
// create a file to write the data to 
using ( var outStream = new IsolatedStorageFileStream("foo.txt", FileMode.Create, isf) ) 
{
    using ( var sw = new StreamWriter(outStream) ) 
    {
    	// write out the text
        sw.Write("Random text");
        sw.Close();
    }
}

And here is how you can retrieve it:

IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForAssembly();
// open the file
using ( var inStream = new IsolatedStorageFileStream("foo.txt", FileMode.Open, isf) ) 
{
    string[] files = isf.GetFileNames("foo.txt");
    if ( files.length > 0 )
    {
        StringBuilder sb = new StringBuilder();
        foreach ( var file in files )
        {
            using ( var sr = new StreamReader(inStream) )
            {
                sb.AppendLine(sr.ReadLine());
            }
        }
    }
}

This method is a much more "enterprise-y" way to access data in your applications.

Saturday, August 09, 2008 3:45:26 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C#

Have you ever found the need to use a temporary directory on the file system in your code?  This issue came up with me recently (and bit me in the ass), so I thought I would share some experiences on how I overcame the problem. 

At the root of the problem is that you need some sort of permanent storage, but nothing that is stringent enough to require it reside in some "known" directory where it can be accessed at a later time.  You don't really care where you store a file, but you need to store it somewhere. 

I recently came across a piece of code in a unit test that serialized a class using the XmlSerializer.  The person who wrote the test must have wanted to see what the class looked like in serialized form.  The code was written so that the xml version of the class was dumped to the file system.  However, when the test was written, the file was hard-coded to the C:\Temp directory. 

As part of my task, I was incorporating the unit tests on this component into the continuous build.  Guess what happened when the test was moved the build server?  FAIL!!!  No C:\Temp directory on that machine means lots of red on the build server and the IT director screaming WTF?!?!?

The lesson is, never make assumptions when accessing the file system.  In this case, the test was counting on the directory both existing and the user having permissions to it.  Obviously, that's not a good idea.

There are other ways to get to a valid "temporary" directory in .Net.  The following code sample shows how you can try a few known places in .Net that should work as "temporary" directories.

/// <summary>
/// Get a valid "temporary" directory on the machine that is running this code 
/// </summary>
/// <returns>a temporary directory</returns>
private string GetTemporaryDirectory() 
{ 
    // try this first 
    string dir = Path.GetTempPath(); 
    if ( String.IsNullOrEmpty(dir) || !Directory.Exists(dir) ) 
    { 
        // see if the "TEMP" environment variable is set 
        dir = Environment.GetEnvironmentVariable("TEMP"); 
        if ( String.IsNullOrEmpty(dir) || !Directory.Exists(dir) ) 
        { 
            // hmmm ... let's create one in "My Documents" 
            string myDocsDir = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments); 
            if ( String.IsNullOrEmpty(myDocsDir) || !Directory.Exists(myDocsDir) ) 
            { 
                // no "My Documents" directory??? 
                throw new Exception( 
                    "Cannot determine a valid temporary directory on this system. " + 
                    "Please set a valid directory for the \"TEMP\" environment variable."); 
            } 
            dir = String.Format("{0}\\Temp", myDocsDir); 
            if ( !Directory.Exists(dir) ) 
            { 
                Log.Info("Creating new Temp directory in {0}", myDocsDir); 
                Directory.CreateDirectory(dir); 
            }  
        } 
    } 
    if ( dir.EndsWith("\\") ) 
    { 
        // cut the last char off 
        dir = dir.Substring(0, dir.Length - 1); 
    } 
    return dir; 
}

The code example above tries to use the .Net libraries to query the file system for some well-known directories that can be used for temporary files.  If a valid one is not found, it will try to create a "Temp" directory in the current user's "My Documents" directory.  At worst, the user should have access to this directory, and the build should not break based on a hard-coded assumption.

Friday, August 08, 2008 12:46:30 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C#

I ran into a piece of code today similar to this:

public class Base
{
    public Base()
    {
        this.Initialize();
    }

    protected virtual void Initialize()
    {
        Debug.WriteLine("Base.Initialize()");
    }
}

public class Derived : Base
{
    public Derived() : base() {}

    protected override void Initialize()
    {
        base.Initialize();
    }
}

public class FurtherDerived : Derived
{
    public FurtherDerived() : base() {}

    protected override void Initialize()
    {
        Debug.WriteLine("FurtherDerived.Initialize()");
    }
}

public class Tester
{
    public static void Main(string[] args)
    {
        Base myBase = new Base();

        Derived myDerived = new Derived();

        FurtherDerived myFurtherDerived = new FurtherDerived();

        Console.ReadLine();
    }
}

See any problems here?  Even though the compiler lets you call virtual methods from a base constructor, it's generally a "bad idea".  That's because the constructor in the derived classes defers its construction up to its base classes before it executes its own constructor (even if we don't explicitly call the base constructor like in the example).  Yet the call to a virtual function in the base class constructor is executed in the derived class implementation.  This can cause subtle, unexpected problems.

In the example above, things "happen" to go well.  It actually runs just fine.  It outputs the following as you'd probably expect:

Base.Initialize()
Base.Initialize()
FurtherDerived.Initialize()

But that's only because we didn't do anything significant in the derived constructors.  What happens if we change the FurtherDerived class:

public class FurtherDerived : Derived
{
    StringBuilder _sb;

    public FurtherDerived() : base()
    {
        _sb = new StringBuilder();
    }

    protected override void Initialize()
    {
       _sb.Append("FurtherDerived.Initialize()");
       Debug.WriteLine(_sb.ToString());
    }
}

Guess what happens when we run this code? FAIL!!! The dreaded, "Object reference not set to a reference of an object". Since the Initialize() method in the FurtherDerived class is called from the Base constructor, we are trying to access the _sb class level parameter before it's ever initialized.  We are calling a method on an class we know has not been fully constructed.  That ain't good.

The lesson is - never call a virtual method from a constructor.  At best, you are introducing a bug waiting to happen.  At worst, you've already done so.

Friday, July 18, 2008 11:57:17 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | Back To Basics | C#

Every project ends up with one or even possibly many static helper classes.  If you program in Java, I'm willing to bet the house your project has a StringUtil class lurking around somewhere.  These classes are easily abused, but can serve a valid purpose, such as a factory class responsible for creating instances. 

If these classes contain only static methods (as they usually do), there is never any reason for them to to be instantiated.  However, in both Java and C#, it's easy to forget that if you do not explicitly declare a constructor, the compiler will generate a no-arg constructor by default.  The consequence is that the following code is valid:

StringUtil util = new StringUtil();

You've just allocated memory unnecessarily.  Plus, the garbage collector will now incur extra overhead since it will have to reclaim this memory even though it was never actually used.  All of the methods are static, so there is no reason to instantiate an individual object from this class. 

To avoid instantiations, make sure you declare a private no-arg constructor.  This will cause the compiler to throw an error any time the class is attempted to be instantiated.

public class StringUtil
{
    // constructor marked private since all methods are static
    private StringUtil() {}

    // bunch of static methods not shown
}

A side note - If you are using C# 3.0, I recommend using extension methods to enhance the behavior of existing classes rather than creating a something like a dedicated StringUtil class.  First of all, any class declaring extension methods has to be marked as static and cannot be instantiated.  And more importantly, it provides a much cleaner implementation to add those helper methods directly on the affected class.  The added bonus is that Visual Studio is smart enough to provide Intellisense for extension methods on targeted classes.

Sunday, June 22, 2008 9:35:25 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Back To Basics | C# | Java | Programming

Scripting languages like Ruby and Groovy recognize the importance of collections like lists and maps, treating them almost like first class objects.  By doing so, they make it really easy to create collections like these and populate them all in one step.

For example, in Ruby here is how this is done:

# create a list
lst = [1, 2, 3, 4, 5]
# create a map
map = { "one" => 1, "two" => 2, "three" => 3 }

Not surprisingly, we see very similar syntax in Groovy...

// create a list
def lst = [1, 2, 3, 4, 5]
// create a map
def map = ["one":1, "two":2, "three":3]

And in case you missed it, one of the changes in C# 3.0 was the ability to initialize collections similar to the way it's done in these scripting languages (though the syntax is not *quite* as clean):

// create a list
var lst = new List<int> { 1, 2, 3, 4, 5 };
// create a map
var map = new Dictionary<string, int> { {"one", 1}, {"two", 2}, {"three", 3} };

IMO, the new collection initializers (along with property initializers) are one of the nicest changes in the new version of the .Net framework.  And since I'm feeling nice, I won't show how this is accomplished in native Java. 

Saturday, June 14, 2008 8:23:10 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  C# | Groovy | Ruby

This new release contains significant changes.  First and foremost, all the implementation classes have had their public scope removed, so you will now have to program exclusively against the interfaces.  I have also moved the IMiadoDao interface to IMiadoRepository in order to encourage composition and not force an inheritance hierarchy.  Combined with that change, I also moved the functionality from SimpleSql into IMiadoRepository, as well as making that interface the point where you access an IDbStatement, making the IMiadoRepository the main worker module of Miado.   Another change is that you need to use the MiadoRepositoryFactory to create an instance of the IMiadoRepository.

Enough with the talk, let's see some code...

public AdddressDao 
{
    private static readonly string INSERT_ADDRESS_SQL = 
        "insert into Address(Address1, Address2, City, State, ZipCode) " +
        "values(@Addr1, @Addr2, @City, @State, @ZipCode)";
        
    private static readonly string SELECT_ADDRESS_SQL = 
        "select AddressId, Address1, Address2, City, " +
        "State, ZipCode " +
        "from Address ";
    
    private static readonly string SELECT_ADDRESS_BY_ID = 
        SELECT_ADDRESS_SQL + "where AddressId = @Id ";
        
    private static readonly string SELECT_ADDRESS_BY_ZIP_CODE =
        SELECT_ADDRESS_SQL + "where ZipCode = @ZipCode ";
        
    private static readonly string SELECT_COUNT_BY_STATE = 
        "select count(*) from Address where State = @State ";

    // uses MiadoRepositoryFactory.CreateMiadoRepository()    
    public AddressDao() 
        : this(MiadoRepositoryFactory.CreateMiadoRepository(
                   SqlClientFactory.Instance, 
                   ConfigurationManager.ConnectionStrings["MyConnection"].ConnectionString)) {}

    public AdddressDao(IMiadoRepository repository) 
    {
        this.MiadoRepository = repository;
    }
    
    protected IMiadoRepository MiadoRepository 
    {
        get;
        set;
    }
    
    public void SaveAddress(Address addr)
    {
        // uses SQL right in IMiadoRepository
        this.MiadoRepository
            .ExecuteNonQuery(INSERT_ADDRESS_SQL, 
                             addr.Address1,
                             addr.Address2,
                             addr.City,
                             addr.State,
                             addr.ZipCode)
    }
     
    public ICollection<Address> FindAddressesByZipCode(string zipCode) 
    {
        // build IDbStatement and do the mapping in a lambda expression 
        ICollection<Address> addresses = 
            this.MiadoRepository
                .CreateDbStatement(SELECT_ADDRESS_BY_ZIP_CODE)
                .AddParameter("ZipCode", zipCode)
                .QueryForResults<Address>(
                    row => new Address() 
                    {
                        AddressId = row.GetValue<int>("AddressId"), 
                        Address1 = row.GetValue<string>("Address1"),
                        Address2 = row.GetValue<string>("Address2"),
                        City = row.GetValue<string>("City"),
                        State = row.GetValue<string>("State"),
                        ZipCode = row.GetValue<string>("ZipCode")
                    });
        return addresses;
    }
     
    public Address LoadAddress(int addrId) 
    {
        // uses delegate method to do the mapping
        return 
            this.MiadoRepository
                .CreateDbStatement(SELECT_ADDRESS_BY_ID)
                .AddParameter("Id", addrId)
                .QueryForOne<Address>(CreateAddress);
    }
     
    public int FindCountByState(string state) 
    { 
        return 
            this.MiadoRepository
                .CreateDbStatement(SELECT_COUNT_BY_STATE)
                .AddParameter("State", state)
                .QueryForOne<int>(row => row.GetValue<int>(0));
    }
     
    private static Address CreateAddress(IResultSetRow row) 
    {
        return 
            new Address() 
            {
                AddressId = row.GetValue<int>("AddressId"), 
                Address1 = row.GetValue<string>("Address1"),
                Address2 = row.GetValue<string>("Address2"),
                City = row.GetValue<string>("City"),
                State = row.GetValue<string>("State"),
                ZipCode = row.GetValue<string>("ZipCode")
            };
    }
    
}

Friday, May 30, 2008 10:57:03 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C# | Miado

Igor Ostrovsky recently published a great blog post about 7 tricks for using LINQ to simplify your programs.  Posts like this really make me re-evaluate how I am writing my code in C# 3.0.  For example, I had written a piece of code for my current project that generates a random confirmation number for a reservation system.  After reading Igor's post, I built off one of his examples and refactored my code to use LINQ to build my confirmation number.  I must admit, the refactored code is much more elegant:

private static readonly char[] AVAILABLE_CHARS =
    "ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789".ToCharArray();

private static string GenerateConfirmationNumber(int length) 
{
    int lastIndex = AVAILABLE_CHARS.length - 1;
    Random rand = new Random();
    var confNbr = 
        Enumerable.Repeat<int>(0, length) // loop N times
                  .Select<int, int>(loopNbr => rand.Next(0, lastIndex)) // get a random index
                  .Select<int, char>(index => AVAILABLE_CHARS[index]) // pull a char
                  .ToArray(); // project the results to a char[]
    return new String(confNbr);
}

I think it's important to remember that LINQ is much, much more than just LINQ-to-SQL (which is what most people immediately think of when you refer to LINQ).  In fact, none of the examples in Igor's post have anything to do with SQL.  Take a look at his post (and other LINQ examples online) and hopefully it will give you ideas on how to code using more of a dynamic language type syntax.

Wednesday, May 21, 2008 9:42:57 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C# | Linq

In my last post, I showed an example of how you can create an extension method on an existing class in javascript.  Well, C# 3.0 has now added the exact same functionality.  And it just so happens that today I needed to create one, so I thought I would post an example of how it's done in C#.

public static class StringExtensions 
{
    public static byte[] ToByteArray(this string s) 
    {
        return ASCIIEncoding.UTF8.GetBytes(s); 
    } 
}

Extension methods act like static methods on existing classes, and as such they can only be declared in static classes. To mark a method as an extension method, you must preface the declaration of the first parameter in the method signature with the keyword "this". The compiler will then add the method to the type of class declared in the first parameter. Any other parameters declared after the first one will become the signature to the extension method.

Now we can call the extension method we added to the String class:

public class Program 
{
    public static void Main(string[] args) 
    {
        string myString = "Foo";
        byte[] bytes = myString.ToByteArray(); 
    } 
}

The other cool thing is that Visual Studio provides full Intellisense on all extension methods!  So in the example I provided, ToByteArray() is now offered up as a potential method anytime I reference a string.

Wednesday, May 14, 2008 12:43:26 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | C#