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

Question

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; }
}

Wyatt Barnett · Accepted Answer · 2011-05-09 15:19:25Z

4

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.

answered May 9, 2011 at 15:19

Wyatt Barnett

15.7k3 gold badges37 silver badges54 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

Yuck Over a year ago

Luckily for me this application is relatively simple and doesn't contain many M:N relationships. Can you elaborate on why you had to allow nullable columns for EF to play nicely? No XML types, at least not in the LOB areas. I am also using repository, and hoping to wrap it with WCF before release. +1 for ReSharper as well!

Wyatt Barnett Over a year ago

Probably my mistake up front -- hangover from the old days, but we avoided int? values here so we setup some "nullable" relationships as "foregin key ID or -1 for null" under the hood which didn't work at all with EF, it expects that FK column to be nullable.

Joel C · Accepted Answer · 2011-05-09 15:35:18Z

1

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).

answered May 9, 2011 at 15:35

Joel C

5,5871 gold badge23 silver badges32 bronze badges

1 Comment

Yuck Over a year ago

Thanks, this is good info on associations. Seems a lot simpler in EF.

Collectives™ on Stack Overflow

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

2 Answers 2

2 Comments

1 Comment

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

1 Comment

Your Answer

Sign up or log in

Post as a guest

Related