Let’s start to kick it up a notch when talking about the new Database Accessors in Enterprise Library 5 DAAB. So far I have only been talking about the basics in the following tutorials:
- - Database Accessors in Enterprise Library 5 DAAB - Database.ExecuteSprocAccessor
- - EnterpriseLibraryContainer and IServiceLocator in Enterprise Library 5
- - Database.ExecuteSqlStringAccessor and LINQ in Enterprise Library 5 DAAB
IRowMapper and IResultSetMapper in Enterprise Library 5 DAAB
Thus far all of the examples with Database.ExecuteSprocAccessor and Database.ExecuteSqlStringAccessor have assumed we are returning all the properties associated with an entity and have let the DAAB take care of managing the resultset and binding of each row to an entity.
This is fine and dandy in our safe little sandbox, but in the real-world we often need to get dirty and have more control of the binding. If you look at the overloads of ExecuteSprocAccessor and ExecuteSqlStringAccessor, you will notice the option of specifying an IRowMapper or an IResultSetMapper for that extra level of control.
In this tutorial we are going to look at IRowMapper, which gives us more control over handling the binding of each row in the resultset. Later we will take a look at IResultSetMapper, which gives us control over not only the binding of individual rows but the entire resultset.
IRowMapper and MapBuilder
In the real world we are not always returning all properties of an entity with each request to the database. In these cases we may need to provide a custom IRowMapper that specifies the subset of properties to be bound. The simplest way to create a custom IRowMapper is to use MapBuilder that comes with the DAAB. MapBuilder provides a fluent interface for specifying which properties are being bound to an entity and returns an IRowMapper when you call Build.
You may not have realized it thus far, but we have been using MapBuilder indirectly the entire time. Since we have not specified a custom IRowMapper, the DAAB has been using MapBuilder<Contact>.BuildAllProperties(), which creates an IRowMapper that expects all properties to be returned by the data access request.
In the case below, however, we have chosen to only return the Id and Email for each contact and have skipped Name. In this case we need to specify a custom IRowMapper. We can do so quite easily by using MapBuilder and specifying all properties are to be bound except for Name. The code is shown below.
class Program
{
static void Main(string[] args)
{
var database = EnterpriseLibraryContainer.Current
.GetInstance<Database>();
var contacts = database.ExecuteSqlStringAccessor<Contact>
("SELECT Id, Email FROM Contacts",
MapBuilder<Contact>
.MapAllProperties()
.DoNotMap(c => c.Name)
.Build());
foreach (var contact in contacts)
Console.WriteLine(string.Format
("{0}: {1}", contact.Id, contact.Email));
Console.ReadLine();
}
}
public class Contact
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
}
If you inspect each Contact in the foreach loop you will see that the Id and Email were properly bound and the Name is null:
In cases where there are a lot of properties but you are only binding a few, you may want to choose to MapNoProperties() and then add individual properties to be bound.
Conclusion
Now of course you do not need to use MapBuilder to create an IRowMapper. You can create your own implementation of IRowMapper by hand. MapBuilder is just a quick and convenient method of doing so when all you need to do is specify a subset of the properties to be bound.
Looking forward to the ETA of Enterprise Library 5 and Unity 2 on April 14, 2010!
Hope this helps.
