Migrating from LINQ to SQL to Entity Framework "Code First"

As I already have classes for my LINQ to SQL data access solution, what trouble might I run into if I wanted to migrate them over to EFCF instead? I'm hesistant to call this code first as the database does already exist. To be clear, the application is not yet in production so if EFCF wipes out the data it's no real loss.

Can I take a class such as the one that follows and simply use it in EFCF? Should I or must I remove the data annotation attributes?

What needs to change where I have EntityRef and EntitySet?

[Table]
public class PlanMember {
    private EntityRef<SystemUser> _caseManager;
    private EntityRef<PlanMemberStatus> _status;

    public PlanMember() {
        this.PlanMemberView = new Views.PlanMember();
    }

    [Column(
        IsPrimaryKey = true,
        IsDbGenerated = true,
        AutoSync = AutoSync.OnInsert
    )]
    public Int64 ID { get; set; }

    [Column]
    public DateTime? BirthDate { get; set; }

    [Column]
    public String City { get; set; }

    [Column]
    public String FirstName { get; set; }

    [Association(ThisKey = "CaseManagerID", Storage = "_caseManager")]
    public SystemUser CaseManager {
        get { return (this._caseManager.Entity); }
        set { this._caseManager.Entity = value; }
    }

    [Column]
    public String CaseManagerID { get; set; }

    [Column]
    public Boolean IsActive { get; set; }

    public Boolean IsEligible {
        get { return (this.PlanMemberView.IsEligible); }
    }

    [Column]
    public String LastName { get; set; }

    [Column]
    public String MedicalRecord { get; set; }

    [Column]
    public String MemberNumber { get; set; }

    [Column(Name = "PCPFullName")]
    public String PrimaryCarePhysicianFullName { get; set; }

    [Association开发者_运维百科(OtherKey = "PlanMemberID")]
    public Views.PlanMember PlanMemberView { get; set; }

    [Column]
    public Int32 PostalCode { get; set; }

    [Column]
    public String Sex { get; set; }

    [Column]
    public String State { get; set; }

    [Association(ThisKey = "StatusID", Storage = "_status")]
    public PlanMemberStatus Status {
        get { return (this._status.Entity); }
        set { this._status.Entity = value; }
    }

    [Column]
    public Int32 StatusID { get; set; }
}

We migrated an application from Linq to Sql to EF POCO generation but haven't tried code first as it wasn't baked at the time. Was really not horribly difficult. The main pain point in our case was the following differences:

• Linq to Sql handles many to many relationships using a separate "bridge" object, EF treats those relationships as collections of various sorts. This changes lots of semantics and can cause lots of code to change, especially if you let entities creep into the UI.
• Another pain point was nullable and non-nullable relationships. Linq to Sql was a bit more forgiving here, but for EF to play well we needed to allow nullable columns some places we traditionally had not.
• Linq to Sql and EF data mapping sometimes have different ideas about what CLR types to map to. Xml columns were our major pain point but you might not have any of those.
• Big trick/nightmare was how to get rid of the l2s bits without breaking everything horribly as linq to sql generates your entities.

This is not something I would try without a pretty effective set of unit tests to give you an automated basis to give you pretty regular temperature readings. Our other godsend was we had a pretty solid Repository pattern implementation -- nothing was talking directly to the EF/Linq2Sql bits but two classes implementing IRepository. Basically, this is a great test for how disciplined you were in implementing your architecture. Also, it is an occasion when you realize that resharper is worth every cent.

To answer your one direct question, I don't think the attributes will necessarily matter but I would remove them so as not to have any potential confusion and/or namespace collisions.

Assuming your classes are named the same as your database tables, and the properties of your classes match the database column names, you should be able to delete all the attributes and use these same classes as your EF code-first model (I don't think you have to delete the attributes, but unless you plan to continue using them in a Linq2Sql model, there's no reason to keep them, and since some things will probably change in the migration, it would probably be best to delete them since your new entities may not still be able to work in Linq2Sql). If your classes don't match your database schema, Scott Guthrie has a blog post about Entity Framework 4 "Code-First": Custom Database Schema Mapping.

What needs to change where I have EntityRef and EntitySet?

A relation defined as EntityRef<OtherEntity> can be replaced with a property of just type OtherEntity, and an EntitySet<OtherEntity> can become an ICollection<OtherEntity> or anything that implements ICollection<T> such as an IDbSet<OtherEntity> (I believe a DbSet<T> is what you would get if you were generating the model from your existing database).