I don't need/want a key!

I have some views that I want to use EF 4.1 to query. These are specific optimized views that will not have keys to speak of; there will be no deletions, updates, just good ol'e select.

But EF wants a key set on the model. Is there a way to tell EF to move on, there's nothing to worry about?

More Details

The main purpose of this is to query against a set of views that have been optimized by size, query parameters and joins. The underlying tables have their PKs, FKs and so on. It's 开发者_StackOverflow中文版indexed, statiscized (that a word?) and optimized.

I'd like to have a class like (this is a much smaller and simpler version of what I have...):

public MyObject //this is a view
{
   Name{get;set}
   Age{get;set;}
   TotalPimples{get;set;}
}

and a repository, built off of EF 4.1 CF where I can just

public List<MyObject> GetPimply(int numberOfPimples)
{
    return db.MyObjects.Where(d=> d.TotalPimples > numberOfPimples).ToList();
}

I could expose a key, but whats the real purpose of dislaying a 2 or 3 column natural key? That will never be used?

Current Solution

Seeming as their will be no EF CF solution, I have added a complex key to the model and I am exposing it in the model. While this goes "with the grain" on what one expects a "well designed" db model to look like, in this case, IMHO, it added nothing but more logic to the model builder, more bytes over the wire, and extra properties on a class. These will never be used.

There is no way. EF demands unique identification of the record - entity key. That doesn't mean that you must expose any additional column. You can mark all your current properties (or any subset) as a key - that is exactly how EDMX does it when you add database view to the model - it goes through columns and marks all non-nullable and non-computed columns as primary key.

You must be aware of one problem - EF internally uses identity map and entity key is unique identification in this map (each entity key can be associated only with single entity instance). It means that if you are not able to choose unique identification of the record and you load multiple records with the same identification (your defined key) they will all be represented by a single entity instance. Not sure if this can cause you any issues if you don't plan to modify these records.

EF is looking for a unique way to identify records. I am not sure if you can force it to go counter to its nature of desiring something unique about objects.

But, this is an answer to the "show me how to solve my problem the way I want to solve it" question and not actually tackling your core business requirement.

If this is a "I don't want to show the user the key", then don't bind it when you bind the data to your form (web or windows). If this is a "I need to share these items, but don't want to give them the keys" issue, then map or surrogate the objects into an external domain model. Adds a bit of weight to the solution, but allows you to still do the heavy lifting with a drag and drop surface (EF).

The question is what is the business requirement that is pushing you to create a bunch of objects without a unique identifier (key).

One way to do this would be not to use views at all.

Just add the tables to your EF model and let EF create the SQL that you are currently writing by hand.