Entity Framework Design - несколько «представлений» для данных

Question

У меня есть вопрос проектирования, связанный с сущностями Entity Framework.

Я создал следующую сущность:

public class SomeEntity {
    // full review details here
}

Эта сущность имеет в качестве примера 30 столбцов.Когда мне нужно создать новую сущность, это прекрасно работает.У меня есть все обязательные поля для вставки в базу данных.

В моем приложении есть несколько мест, где мне нужно отобразить некоторые табличные данные с некоторыми полями из SomeEntity, но я ненужно все 30 столбцов, может быть, только 2 или 3 столбца.

Создаю ли я совершенно новую сущность, в которой есть только нужные мне поля (которая сопоставляется с той же таблицей, что и SomeEntity, но извлекает только нужный мне столбец?)

Или это делаетимеет смысл создать класс домена (например, PartialEntity) и написать запрос, подобный следующему:

var partialObjects = from e in db.SomeEntities
                     select new PartialEntity { Column1 = e.Column1, Column2 = e.Column2 };

Я не уверен, каков подходящий способ сделать этот тип вещи.Это плохая идея иметь две сущности, которые отображаются на одну и ту же таблицу / столбцы?На самом деле мне никогда не понадобится возможность создавать PartialEntity и сохранять его в базе данных, потому что он не будет иметь все необходимые поля.

Answer 1

Ваш первый подход невозможен.EF не поддерживает несколько сущностей, сопоставленных с одной и той же таблицей (за исключением некоторых особых случаев, таких как наследование TPH или разбиение таблицы).

Второй случай - это распространенный сценарий.Вы создадите модель представления для вашего пользовательского интерфейса и либо спроектируете свою сущность для просмотра модели непосредственно в запросе (она будет передаваться из БД только для столбцов, которые вы проецируете), либо вы запросите всю сущность и выполните преобразование для просмотра модели в коде вашего приложения (например, с помощьюAutoMapper, как упомянуто @Fernando).

Если вы используете файл EDMX для отображения (я полагаю, вы этого не сделаете, потому что вы упомянули ef-code-first ), вы можете использовать третий подход, который требуетчасть из обоих упомянутых подходов.Этот подход определяет QueryView - это основанное на EF представление сопоставленного объекта, которое ведет себя как новый объект только для чтения.Обычно это многоразовая проекция, хранящаяся непосредственно в картографии.

Answer 2

То, что вы предложили в качестве первого решения, - это «парадигма представления модели», где вы создаете класс с единственной целью - стать моделью представления для извлечения данных, а затем сопоставить его с классом модели.Вы можете использовать AutoMapper для сопоставления значений.Вот статья о том, как применить это.

Answer 3

Я думаю, что это добавит ненужную сложность вашей модели, чтобы добавить вторую сущность, основанную на той же структуре данных.Я, честно говоря, не вижу проблемы в наличии единой сущности для обновления \ редактирования \ просмотра.Если вы настаиваете на разделении доступа к SomeEntity, вы можете иметь представление базы данных: т.е. SomeEntityView и создавать отдельную сущность на основе , что .

Answer 4

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