Make a MustOverride (abstract) member with EF 4?

I have an abstract class Contact.

It leads to two subclasses:

1. Company (Title)
2. Person (FirstName, LastName)

I want to add a computed 'Title' col in the Person table, that return FirstName + ' ' + LastName, which will g开发者_Python百科ive me better search options.

So I want to create the Contact table have an abstract property Title, which each of these two implements, and so, I will be able to use:

Dim contacts = From c In context.Contacts
               Where c.Title.Contains("Nash")

I am pretty sure this is impossible, the question is what is the efficient alternative way?

In my scenario I have a ListBox showing all the Contacts of both Company and Person types, I have a search TextBox and I want the Service query (GetContacts(searchQuery As String)) to query the filtered set against the DB.

Update

After Will's answer, I decided to create in the Person table a computed col as above. The question is what what be the most efficient way to imlpement the WCF-RIA query method:

Public Function GetContacts(searchQuery As String) As IQueryable(Of Contact)
  'Do here whatever it takes to retieve from Contacts + People 
  'and mix the results of both tables ordered by Title
End Function

Unfortunately, while there is a way to do this with partial classes, I am 99% sure you cannot mix linq queries that touch entity properties and "POCO" properties defined in a partial class.

The Linq to Entity context will actually convert these queries to sql, and it cannot handle situations where a particular method isn't directly supported by the context. A common example for L2E is the inability to use enums in your query. Like knowing how to handle enums, the context certainly doesn't know how to handle your POCO properties when converting to raw sql.

An option you might want to investigate is to create a the computed column within your database, or to run your queries, do the traditional ToArray() in order to trigger enumeration, and then examine the computed column in memory. This might not be a good solution, depending on the size of your table, however.

So, essentially, you wish to search two disparate types (backed by two different tables) and then combine the results for display to the user.

I would have to say that polymorphism is NOT the best solution. The desire to show them in the UI shouldn't force a design decision all the way down into your type definitions.

I have done something similar a few times before in WPF. I've done it two ways; by using polymorphism in the form of facade types which wrap the models and which can be treated by a common base type, and by treating all the different types in the collection as System.Object.

The first way is okay when you need type safety and the ability to treat different types the same way. The wrappers extend a common base class and are coded to "know" how to handle each of their wrapped types correctly.

The second way is okay when you don't need type safety, such as when exposing a collection to a WPF View where you are displaying them in an ItemsControl, which can figure out the correct DataTemplate to use by the type of each instance in the collection.

I'm not sure which way is best for you, but whichever it is, you should query both your Company and Person tables separately, Union the two result sets, then sort them appropriately.

Pseudocode:

//Wrapper version
var results  = Company
               .Where(x=>x.Title.Contains(searchTerm))
               .Select(x=> new CompanyWrapper(x))
               Cast<BaseWrapper>().Union(
                  Person
                      .Where(x=>x.ComputedTitle.Contains(searchTerm))
                      .Select(x=> new PersonWrapper(x))
                      .Cast<BaseWrapper>());

//System.Object version
var results  = Company
               .Where(x=>x.Title.Contains(searchTerm))
               Cast<object>().Union(
                  Person
                      .Where(x=>x.ComputedTitle.Contains(searchTerm))
                      .Cast<object>());

In both cases, you may not have to downcast specifically. Again, the first gives you type safety if you need it in the UI, the second is simpler and requires less code on the backend but is only useful if you don't require type safety in the UI.

As for sorting, once you've searched and combined your result, you can OrderBy to sort the result, however you will have to provide a function which can perform the ordering. This function will differ depending on which version you choose.