I've started work on the search piece of our application.  Searching (no pun intended) for some inspiration on how users might want to search within our application, I brought up the current WinForms version, and then the ASP.NET version.

I realized that we need to make searching easier in WinForms client, currently when searching for a patient in our WinForms client, you are presented with a separate text box for first name, last name, SSN, date of birth, and health record number.  Our ASP.NET client presents just one text box to search all of those fields.

Tying the Domain Model to the Data Access Layer

So I started thinking about all the pieces in our domain model that we might want to allow the user to search.  Then I realized that to allow searching across all the fields in an entity would tie the data access layer (DAL) to  the domain model ala something like this:

public IList<Patient> Search(string text)
{
  ICriteria criteria = session.CreateCriteria(typeof(Patient));
  Disjunction or = Expression.Disjunction();
  text = string.Format("%{0}%", text);
  or.Add(Expression.Like("FirstName", text));
  or.Add(Expression.Like("MiddleName", text));
  or.Add(Expression.Like("LastName", text));
  crit.Add(or);
  return criteria.List<Patient>();
}

Custom Attributes

I started doing some thinking about how unit testing frameworks such as MbUnit work and realized I could use .NET custom attributes and some reflection to solve the problem.

I came up with an attribute called Search, currently it takes in one boolean parameter called Enabled.

 1 using System;
 2 using System.Reflection;
 3 
 4 [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
 5 public class SearchAttribute : System.Attribute
 6 {
 7     public bool Enabled;
 8 
 9     /// <summary></summary>
10     /// </summary>
11     /// <param name="Enabled">if true, property will be included in object-level searches</param>
12     public SearchAttribute(bool Enabled)
13     {
14         this.Enabled = Enabled;
15     }
16 }

I could have written it as:

1 using System;
2 using System.Reflection;
3 
4 [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
5 public class SearchAttribute : System.Attribute { }

But I wanted the flexability of adding named parameters in the future.  Who knows, maybe this is a lame reason, and I should just refactor the code if I want to add parameters to it in the future.

Adding the Attribute to Your Domain Model

The interesting thing about a custom attribute, is if it ends in Attribute (i.e. SearchAttribute), its name gets changed to Search by the C# compiler(?), although you could still use SearchAttribute as the name when you add it to your properties.  If you look at the IL, its still called SearchAttribute:

.custom instance void MyNamespace.SearchAttribute::.ctor(bool) = ( bool(true) )

But if you change the attribute name to SearchAttrib, or SearchAttributes, then you have to use the full name when decorating the properties in your class.  This really isn't germane to the topic at hand, I just thought it was neat! :)

Example:

 1 public class Patient
 2 {
 3     [Search(true)]
 4     public string FirstName
 5     {
 6         get { return _firstName; }
 7         set { _firstName = value; }
 8     }
 9 ...
10 }

Pulling it All Together

The custom attribute is great and all, but it doesn't inherently buy us anything.  We need to add a little bit more magic to make all this work.  This is a simplified version of what I ended up putting in my DAL base class:

 1 private IList<Patient> Search(string text)
 2 {
 3     Type type = typeof(Patient);
 4     ICriteria criteria = _session.CreateCriteria(type);
 5 
 6     Disjunction or = Expression.Disjunction();
 7     foreach (PropertyInfo propInfo in type.GetProperties())
 8     {
 9         //SearchableAttribute is AllowMultiple = false, so we only need the first item
10         Attribute[] attribs = Attribute.GetCustomAttributes(propInfo, typeof(SearchAttribute));
11         if (attribs.Length == 0)
12             continue;
13 
14         if (((SearchAttribute)attribs[0]).Enabled)
15             or.Add(Expression.InsensitiveLike(propInfo.Name, string.Format("%{0}%", text)));
16     }
17     criteria.Add(or);
18     return criteria.List<T>();
19 }
20 

Again, this is a simplified version of what's in our DAL base class, the actual signature looks more like this: private IList<T> Search<T>(string text) so that I don't have to write a version of this for each class in our domain model I want to enable searching for.

Everything above should be pretty self-explanatory unless you aren't familiar with the NHibernate Criteria API; in which case the Expression.Disjunction bit on line 6 is how you do an OR (a OR b OR c)when searching.  You can also do Expression.Conjunction if you want AND searching (a AND b AND c).

The original version of this code had a second foreach loop which spun through all the attributes on each property looking for the SearchAttribute.  I thought to myself that their had to be a better way and did a little bit of poking around, and discovered much to my delight that the static method Attribute.GetCustomAttributes allows you to specify what kind of attribute you are searching for!

Limitations

In the code above, you'll get an Exception if you try to search against non-text columns in your database so you will need to that into account when putting the Search attribute in your Domain Model; or add some more smarts to the Search method to take into account different data types.

Comments

If you've read down this far, then I'd love to get a comment from you.  Is there anything you think I could do a better job of explaining, am I an awesome guy?  Or do I suck, either way, I'd like to know, so please leave me a comment!

If you like my article, please kick it at .NET Kicks (I have no idea why the kick counter says I have zero kicks btw)!