Search has changed in SharePoint 2010. If you’ve worked with at all, you already know that. In particular, one big change is the new Federated Object Model that’s now available for issuing search queries in server-side code. The updated enterprise search web parts that ship with SharePoint 2010 are built on this new object model.

In a nutshell, the way the federated object model works is by executing queries against federated locations (configured in a search service application). Examples of locations are the local SharePoint search index, FAST Search Server 2010, internet sites like Amazon.com that support OpenSearch, and custom locations you define yourself.

The “gateway” into the federated object model is the QueryManager class (Microsoft.Office.Server.Search.Query namespace in Microsoft.Office.Server.Search.dll). It allows you to register a list of Locations defining where you want to search and execute a query against all of them simultaneously.

In general, the federated object model is a good approach for executing queries in SharePoint 2010 because it abstracts away the details of whatever location(s) you’re searching, allowing you to simply issue a query and retrieve the results.

However, if you want to sort your query results by something other than relevance, it falls a little short.

If you explore the QueryManager class, you’ll find it only has one property related to sorting: the DefaultFASTSearchSort property. Unfortunately that property is only there to be used by the Core Results Web Part and then only for searching FAST Search Server as the name implies. Outside of that context it isn’t very useful.

The next best thing, if it weren’t marked ‘internal’ by Microsoft and inaccessible to us, might be the LocationRuntime property of the Location class. SharePoint 2010 ships with 3 search runtime locations, and two of them (FASTSearchRuntime and SharePointSearchRuntime) support setting sort options before issuing a query.

Unfortunately we can’t get at them to set sort options unless we do something like this video from Microsoft describes. In the video they show how to create a custom search results web part and custom data source view to populate it. The base class for their data source view contains an AddSortOrder() method that allows sort options to be set on the underlying runtime.

So other than the approach in the video, we’re left with at least three other options I can think of:

1. Use the search web service and include the <SortByProperties /> element in our query.
2. Use the KeywordQuery class and its SortList property.
3. Use the FullTextSqlQuery class and an “ORDER BY” clause. However, this approach only supports SharePoint 2010 search and leaves out FAST.