Миграция с LINQ на SQL на Entity Framework «Сначала код» - PullRequest
Новая
       0

Миграция с LINQ на SQL на Entity Framework «Сначала код»

2 голосов
/ 09 мая 2011

Поскольку у меня уже есть классы для моего решения для доступа к данным LINQ to SQL, с какими проблемами я мог бы столкнуться, если бы вместо этого захотел перенести их в EFCF?Я не могу назвать этот код первым, так как база данных уже существует.Чтобы было ясно, приложение еще не запущено, поэтому, если EFCF уничтожит данные, это не будет реальной потерей.

Могу ли я взять класс, подобный следующему, и просто использовать его в EFCF?Должен ли я или должен удалить атрибуты аннотации данных?

Что нужно изменить, если у меня есть EntityRef и 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; }
}

Ответы [ 2 ]

4 голосов
/ 09 мая 2011

Мы перенесли приложение из Linq в Sql в EF POCO, но не пробовали сначала код, так как в то время оно не запекалось.Было действительно не ужасно сложно.Основным болевым моментом в нашем случае были следующие различия:

  • Linq to Sql обрабатывает отношения многие ко многим, используя отдельный объект-мост, EF рассматривает эти отношения как коллекции различного рода.Это меняет много семантики и может привести к изменению большого количества кода, особенно если вы позволяете сущностям проникать в пользовательский интерфейс.
  • Еще одна проблема заключалась в обнуляемых и ненулевых отношениях.Linq to Sql был немного более щадящим, но для того, чтобы EF играл хорошо, нам нужно было разрешить пустые столбцы в некоторых местах, которых у нас традиционно не было.
  • Linq для Sql и EF отображения данных иногда имеют разные представления о том, какие типы CLRдля сопоставления.XML-столбцы были нашей основной проблемой, но у вас их может и не быть.
  • Большой трюк / кошмар заключался в том, как избавиться от битов l2s без ужасного разрушения всего, так как linq to sql генерирует ваши сущности.

Это не то, что я бы попробовал без симпатичногоэффективный набор юнит-тестов, позволяющий автоматизировать процесс измерения температуры.Другой нашей находкой было то, что у нас была довольно солидная реализация шаблона репозитория - ничто не говорило напрямую с битами EF / Linq2Sql, а два класса реализовывали IRepository.По сути, это отличный тест на то, насколько вы дисциплинированы в реализации вашей архитектуры.Кроме того, это тот случай, когда вы понимаете, что resharper стоит каждого цента.

Чтобы ответить на ваш один прямой вопрос, я не думаю, что атрибуты обязательно будут иметь значение, но я бы удалил их, чтобы не иметь никакихпотенциальная путаница и / или столкновения пространства имен.

1 голос
/ 09 мая 2011

Предполагая, что ваши классы названы так же, как таблицы вашей базы данных, а свойства ваших классов совпадают с именами столбцов базы данных, вы должны иметь возможность удалить все атрибуты и использовать эти же классы в качестве модели EF-кода (IНе думайте, что вам нужно удалять атрибуты, но если вы не планируете продолжать использовать их в модели Linq2Sql, нет никаких причин их сохранять, и, поскольку некоторые вещи, вероятно, изменятся в процессе миграции, вероятно, было бы лучше удалить ихпоскольку ваши новые сущности могут все еще не работать в Linq2Sql).Если ваши классы не соответствуют схеме вашей базы данных, Скотт Гатри имеет сообщение в блоге о Entity Framework 4 «Code-First»: сопоставление схемы пользовательской базы данных .

Что нужно дляизменить, где у меня есть EntityRef и EntitySet?

Отношение, определенное как EntityRef<OtherEntity>, может быть заменено свойством просто типа OtherEntity, а EntitySet<OtherEntity> может стать ICollection<OtherEntity> или чем угоднокоторый реализует ICollection<T>, например IDbSet<OtherEntity> (я думаю, DbSet<T> - это то, что вы получите, если бы вы генерировали модель из существующей базы данных).

...