Повторное использование сущностей в платформе Entity для нескольких решений Visual Studio - общие столбцы и различные столбцы - база данных, модель или код в первую очередь?

Question

Мне нужна помощь в выборе метода CRUD для требования отдельных таблиц с общими и разными полями для нескольких корпоративных решений.

Вот упрощенный пример столбцов в таблице с именем Организация в каждой базе данных решения..

Db1: Id (общий) Имя (общий) Address (common) ClientStatus

Db2: Id-адрес Address NoOfEmployees RegistrationStatus

Db3: Id-адрес Address SecondaryAddress

Db4: Id Name Address LinkedId

Справочная информация:

У меня есть клиенты в одной и той же отрасли, и у меня все схожие системы MIS (интерфейс с базой данных), которые я разрабатываю.Функциональная концепция для всех клиентов одинакова, но столбцы таблиц таблицы на 30% различаются, бизнес-правила различаются, и экраны должны соответствовать требованиям каждого уникального клиента.

У каждой клиентской системы есть собственное решение Visual studio и собственная база данных SQL-сервера.Клиенты владеют своей конкретной базой данных и исходным кодом.

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

Просмотр структуры базы данных междуклиентские базы данных таблицы имеют одинаковые имена таблиц.Таблицы имеют 70% одинаковых столбцов таблицы, за исключением того, что добавляются столбцы или новые таблицы для клиента, который является уникальным для этого клиента.Экраны внешнего интерфейса также различаются.

Теперь создание нового решения и его сопровождение занимает много времени из-за того, что трудно различить основной и пользовательский код из-за отсутствия разделения кода между основными полями, правилами и представлениями.и уникальные поля, правила и представления.

Дизайн:

1. Мне нужно разделить общие CRUD и бизнес-правила между решениями
2. Мне нужно сохранить отдельное решение дляуникальный код решения или поля клиента и поля одного клиента не должны содержаться в коде решения и базе данных другого клиента.
3. Мне не нужна отдельная таблица, ссылающаяся на каждую общую таблицу или столбцы с именами custom1, custom2, custom3 в качестве клиентовВ базе данных есть свои собственные инструменты отчетности, которым нужны имена английских столбцов в одной таблице.
4. CRUD должен работать как с MVC3 Razor, так и с интерфейсом Silverlight 4, серверным сервером SQLR 2008R2.
5. Добавлениевпоследствии новые поля БД должны быть простыми и не иметь большого влияния.

My план:

У меня была идея перепроектировать систему, используя базовые классы для имен общих таблиц, например таблицы OrganizationBase, и затем иметь класс, который наследует ее, например, OrganizationExtend содержит уникальные имена столбцов. Затем CRUD объединитполя базового класса и родительского класса вместе и обновите базу данных с помощью ADO.net.Исходный код базовых классов будет разделен между решениями.

Однако я хотел бы использовать структуру сущностей для своих целей, но я не уверен, возможно ли это с помощью EF или EF поддерживает мою цель разделения общих полей с помощьюТаблица уникальных столбцов на дБ и как ее проектировать.Я раньше не использовал EF, но хотел бы использовать RAD.

Мой вопрос:

Возможно ли мое требование с помощью Entity Framework и, если да, то каким образом или какое-либо другое решение CRUD более идеально подходит для этого требования??

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

Answer 1

Сначала база данных и модель сначала используют файлы edmx, которые не подходят для наследования.

Сначала с EFcode вы можете использовать обычные классы C # OO с наследованием и использовать отображение EF для сопоставления унаследованного класса с таблицей.

Так мой код будет выглядеть так:

Классы общего пространства имен между решениями:

public abstract class OrganisationBase
{
    public int OrganisationId { get; set; }
    [Required]
    public string Name { get; set; }
    [Required]
    public string Address { get; set; }
    [Required]
    public string TelNo { get; set; }
}

Классы пространства имен, определенные для клиента 1:

public class Organisation : OrganisationBase
    {
        [Required]
        public int ClientStatusId { get; set; }
    }

Классы пространства имен, специфичные для клиента 2:

public class Organisation : OrganisationBase
{
    [Required]
    public int NoOfEmployees { get; set; }
    [Required]
    public int RegistrationStatusId { get; set; }
}