Can I use the Entity Framework like I use LINQ to SQL?

Question

I've begun experimenting with LINQ to SQL and what I am doing is basically creating classes with LINQ mapping decorators - thereby choosing which parts of the db table schema I want to incorporate into my classes.

A simple example:

private DateTime? _LocalCopyTimestamp = (DateTime)SqlDateTime.MinValue;
[Column(Name = "recaLocalCopyTimestamp", Storage = "_LocalCopyTimestamp", CanBeNull = true)]
public DateTime? LocalCopyTimestamp
{
    get
    {
        return this._LocalCopyTimestamp;
    }
    set
    {
        this._LocalCopyTimestamp = value;
    }
}

I am not using and am not willing to resort to modeling tools due to project contraints (the way schema changes are handled and because there is an existing database schema and it is a bit too organic and non-strict)

Is there a way to have this flexibility with the Entity Framework without having to include schema information files and/or lots of distinct code files?

Could I then also create classes that "use" more than one underlying table?

Can anyone point me to documentation regarding this?

Answer 1

Entity Framework uses the EDM to model data; this is a set of 3 complex schema files (storage, conceptual, mapping), most commonly stored as resources in the project (via the designer which uses a single EDMX file to generate all 3 schema files).

It doesn't support attributed classes for this information. The only sensible way to write EDM is via the designer (essentially, a modelling tool which you dislike).

Re classes the "use" more than one underlying table; yes, a single Entity Framework entity at the conceptual layer (i.e. classes) can span multiple storage tables. This is especially useful for some inheritance examples, but can (IIRC) be used by flat models too. You do this via the "mappings" between the storage and conceptual layers (most commonly; on the tab in the designer).

Answer 2

The feature you are requesting (write C# classes and generate your model from those) is termed by the Entity Framework team "Model First." It does not exist in the current, shipping version of the Entity Framework, but is a planned feature for the next version. If you watch the Entity Framework talks from PDC, you can see demonstrations of this new feature. With the current version, you do not have to write "many" mapping files, but you do need one (the EDMX file), and it must be XML.

Yes, you can create entity classes which use more than one underlying table. This is called "Entity splitting." Step-by-step instructions at the link. In general, you will find that the Entity Framework supports many more complicated mapping scenarios than LINQ to SQL.

I'm afraid that I have to completely disagree with Marc regarding writing EDMX without use of the designer. Writing EDMX without using the designer is not only possible, but for projects exceeding a certain side, it is all but inevitable. A few points on this:

1. For most of the early history (pre-RTM; "ObjectSpaces") of the Entity Framework, writing the XML files manually was the only way to use the tool. The designer is a recent feature, and is considerably less stable than the Entity Framework itself.
2. There are certain Entity Framework features, such as complex types, which are not supported in the designer at all.
3. Certain mapping scenarios, such as not mapping individual columns, or mapping tables without a foreign key relationship, which may be necessary for legacy databases, are not supported in the designer.
4. As I mentioned in (1) the designer is quite a bit buggier than the Entity Framework itself. So on larger projects you will probably end up having to clean up after the designer's mistakes.