Entity Framework - поддержка нескольких проектов - PullRequest
Новая
       13

Entity Framework - поддержка нескольких проектов

2 голосов
/ 18 декабря 2009

Я планирую перенести большой проект на Entity Framework 4.0, но не уверен, что он справится с моим сценарием наследования.

У меня есть несколько проектов, которые наследуются от объекта в «основном» проекте. Вот пример базового класса: 

 namespace People
{
    public class Person
    {
        public int age { get; set; }
        public String firstName { get; set; }
        public String lastName { get; set; }

    }
}

и один из подклассов: 

namespace People.LawEnforcement
{
    public class PoliceOfficer : People.Person
    {
        public string badgeNumber { get; set; }
        public string precinct { get; set; }
    }
}

А вот так выглядит макет проекта:

Люди - Люди. Образование - Люди. Правоохранительные органы http://img51.imageshack.us/img51/7293/efdemo.png

Некоторые пользователи приложения будут использовать классы People.LawEnforcement, а другие пользователи будут использовать People.Education, а некоторые будут использовать оба. Я отправляю только те сборки, которые потребуются пользователям. Таким образом, ассемблеры действуют как плагины в том, что они добавляют функции в основное приложение.

Есть ли в Entity Framework поддержка этого сценария?

Исходя из этого ТАКОГО вопроса Я думаю, что-то подобное может сработать: 

ctx.MetadataWorkspace.LoadFromAssembly(typeof(PoliceOfficer).Assembly);

Но даже если это сработает, оно будет выглядеть так, как будто мой файл EDMX должен будет знать обо всех проектах. Я бы предпочел, чтобы каждый проект содержал метаданные для классов в этом проекте, но я не уверен, возможно ли это.

Если это невозможно с Entity Framework, есть ли другое решение (NHibernate, Active Record и т. Д.), Которое будет работать?

Ответы [ 2 ]

5 голосов
/ 18 декабря 2009

Алекс прав (+1), но я настоятельно призываю вас пересмотреть свою модель. В реальном мире полицейский не является подтипом человека. Скорее, это атрибут занятости этого человека. Я думаю, что программисты часто склонны переоценивать наследование за счет композиции в объектно-ориентированном проектировании, но это особенно проблематично при отображении O / R. Помните, что экземпляр объекта может иметь только один тип. Когда этот объект хранится в базе данных, экземпляр может иметь этот тип только в том случае, если он существует, в нескольких сеансах приложения. Что делать, если у человека было две работы, в качестве офицера полиции и учителя? Возможно, такой сценарий маловероятен, но общая проблема встречается чаще, чем вы могли ожидать.

В большей степени отвечая вашему вопросу, я думаю, что вы можете решить свою настоящую проблему под рукой, сделав модель сопоставленных сущностей более общей, а также свои прогнозы данных для конкретных приложений, а не самих сущностей. Рассмотрим сущности, подобные: 

public class JobType
{
    public Guid Id { get; set; }
    // ...
}

public class Job 
{
    public JobType JobType { get; set; }
    public string EmployeeNumber { get; set; }
}

public class Person
{
    public EntityCollection<Job> Jobs { get; set; }
}

Теперь ваше приложение для правоохранительных органов может: 

var po = from p in Context.People
         let poJob = p.Jobs.Where(j => j.JobType == JobType.PoliceOfficerId).FirstOrDefault()
         where poJob != null
         select new PoliceOfficer
         {
             Id = p.Id,
             BadgeNumber = poJob.EmployeeNumber
         };

Где PoliceOfficer - это просто POCO, а не отображаемая сущность любого вида.

И благодаря этому вы достигли своей цели - иметь общую модель данных, но с элементами "конкретного типа работы" в отдельных проектах.

5 голосов
/ 18 декабря 2009

Да, это возможно, используя метод LoadFromAssembly (..), который вы уже нашли.

... но это будет работать только в том случае, если у вас есть специализированная модель (т.е. EDMX) для каждого отдельного типа клиентского приложения.

Это потому, что EF (и большинству других ORM) требуется класс для каждой сущности в модели, поэтому, если некоторые клиенты не знают о некоторых классах, вам понадобится модель без соответствующих сущностей - то есть настроенный EDMX для каждого сценария.

Чтобы упростить создание новой модели для каждого клиентского приложения, я бы использовал Только для кода , следуя рекомендациям , изложенным в моем блоге, чтобы было проще захватывать только те фрагменты модели, которые вам действительно нужны.

Надеюсь, это поможет

Alex

...