База данных EntityFramework по сравнению с моделью

Question

Я понимаю, что создание модели на основе метода DataBaseFirst приведет к созданию коллекции объектов на ORM, которые по существу сопоставляются с таблицами БД.

Полагаю, что если вам нужны свойства из других объектов или только поля раскрывающегося списка, вы можете создать ViewModel и использовать этот класс в качестве своей модели.

У меня есть курс AppDev, который я только что закончил, и автор написал что-то, что, если я его правильно понимаю, он имеет в виду изменение объектов ORM, чтобы они соответствовали вашим представлениям ViewModels, следовательно, нет необходимости в ViewModels. Однако, если вы это сделаете и восстановите ORM из базы данных, эти новые объекты, которые вы разместили как «ViewModels», исчезнут. Если вы изменили ORM для обновления базы данных, ваша структура базы данных в SQL Server будет «отменена».

Пожалуйста, сообщите мне, если я правильно понял, что мне просто нужно использовать ViewModel в отдельной папке для сбора определенных классов и/или свойств в суперклассе или в одном классе со свойствами, которые мне только нужны, и использовать их как мои модель ....

Настоящая выдержка из автору: EntityFramework - это первоначально сопоставление классов с таблицами один к одному, но вы можете создать модель, которая лучше представляет сущности в вашем приложении независимо от того, как данные хранится в реляционных таблицах.

Answer 1

Я думаю, что автор, возможно, намекнул, - это концепция сложных моделей. Скажем, например, что в вашей базе данных есть таблица Customer и таблица Address. От одного к одному сопоставление создавали бы 2 элемента модели, один класс Customer и один класс Address. Используя сопоставление сложных моделей, вы могли бы создать один класс Customer, который содержал столбцы из таблицы Customer и таблицы Address. Таким образом, вместо Customer.Address.Street1 вы можете просто ссылаться на Customer.Street1. Это лишь один из многих случаев, когда вы могли бы представить концептуальную модель в коде иначе, чем результирующие данные в хранилище. Ознакомьтесь с замечательной серией блога Inheritance with EF CodeFirst для примеров различных стратегий сопоставления, таких как таблица на иерархию (TPH), таблица на тип (TPT), таблица на конкретный класс (TPC). Обратите внимание, что хотя эти примеры и являются CodeFirst, они по-прежнему применяются к Entity Framework, даже если исходные модели генерируются из базы данных.

В общем случае, если вы используете DatabaseFirst, а затем никогда не изменяете результирующие объекты, вы всегда будете иметь класс в коде для каждой таблицы в базе данных. Тем не менее, сила Enity Framework заключается в том, что она позволяет вам более эффективно работать с вашими объектами, разрешая эти гибридные сопоставления, тем самым освобождая вас от вашего кода, без дополнительного бремени ваших классов, которые должны соблюдать жесткие ожидания SQL.

Редактировать

Когда базу данных первые или модели первых сущностей генерируются, они преднамеренно генерируются как частичные классы. Вы можете создавать свои собственные части, которые расширяют классы, созданные из Entity Framework, без изменения существующих файлов классов. Если модели будут сгенерированы повторно, ваши частичные классы будут по-прежнему неповрежденными. Конечно, использование partials означает, что у вас есть поведение по умолчанию для Entity Framework, а также расширенное поведение, но это обычно не является большой проблемой.

Другим вариантом является то, что вы можете изменять файлы TT, которые Entity Framework использует для генерации ваших моделей, гарантируя, что ваши модели всегда восстанавливаются в одном и том же состоянии.

В конечном итоге основная идея заключается в том, что поведение по умолчанию для платформы Entity Framework по умолчанию состоит в том, чтобы сопоставить базу данных с классами 1: 1, есть другие варианты, и вы никогда не вынуждаетесь к чему-то, что неэффективно для вашего проекта.