So many criteria

Question

I'm working on an internet website that provides some services to internet users. So we have a administration system, where my cooperators from the business team can get the information they want, e.g. how many new users registered in the last 3 days? or how many articles posted with the tag "joke" etc. Thus in the administration system, there are a few pages for searching some tables with conditions. These pages are quite alike:

---

UserID:[--------------] Nick Keyword:[------------] Registered Time:[BEGIN]~[END] [Search]

---

The searching results are listed here

---

The class User has more properties than just UserID/Nick/RegisterTime (as well as the user table), but only the 3 properties are treated as conditions. So I have a UserSearchCriteria class like:

public class UserSearchCriteria
{
    public long UserID { get; set; }
    public string NickKeyword { get; set; }
    public DateTime RegisteredTimeStart { get; set; }
    public DateTime RegisteredTimeEnd { get; set; }
}

Then in the data access layer, the search method takes an argument with its type UserSearchCriteria, and build the corresponding Expression<Func<User, bool>> to query. While out of theDAL, other developers can only search the user table with the 3 conditions provided by the criteria, for example, they can't search those users whose City property is "New York"(this is usually because this property has no index in DB, searching with it is slow).

Question 1: This implementation of enclosing the search is correct or not? Any suggestions?

Question 2: Now I find more criteria classes in the project like ArticleSearchCriteria,FavouriteSearchCriteria and etc, and the criteria will become more and more in the future I think. They have almost the same working mechanism but I need to repeat the code. Is there a better solution?

P.S. If you need these info: jQuery + ASP.NET MVC 3 + MongoDB

Answer 1

Makes perfect sense to me. If the user can't search by "anything" then using a search-by-template sort of approach doesn't make any sense. Also, if you try to make this more generic, it will get downright confusing. E.g., I would hate to code to something like:

class SearchCriteria{
   Dictionary<object,object> KeyValuePairs;
   EntityKind Entity;
}

to be used like this:

SearchCriteria sc = new SearchCriteria();
sc.KeyValuePairs.Add("UserId",32);
sc.Entity = EntityKind.User;

Eww. No compile time type checking, no checking to see if the entity and property match up, etc.

So, my answer is, yes :), I would use the design pattern you are currently using. Makes sense to me, and seems straightforward for anyone to see what you're doing and get up to speed.