Entity Framework Core Вступление MSDN

EF Core может использоваться как объектно реляционный модуль сопоставления (O/RM), позволяя разработчикам .NET работать с базой данных с помощью объектов .NET и устраняя необходимость в написании большей части кода https://docs.microsoft.com/ru-ru/ef/core/

(1. большей или более сложной? Можно привести пример для сравнения. Ведь классы создаются для удобства и тем самым механизм непосредственно доступа к БД усложняется за счет прокси клиента(EF например) и это сказывается на быстродействии. Но 2. почему тогда нельзя также генерить код для ADO.NET?

0

Но в EF 1)мы также прописываем пути для доступа к БД, в чем разница? 2)может здесь имеется ввиду параметризированные запросы, тогда можно привести пример для сравнения?

0

Сообщение от MyCyberMan Но в EF 1)мы также прописываем пути для доступа к БД, в чем разница?

Какие такие пути мы прописываем?

0

Сообщение от Usaga Какие такие пути мы прописываем?

Может быть, имеется в виду ConnectionString ?

0

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

0

Не надо путать строку подключения с патернами работы с БД. Можно в одном проекте работать например, с SQLClient, Dapper и EF, используя одно подключение. А можно например с любым из них сразу с несколькими разными подключениями.
Для SQL-сервера нет никакой разницы, от кого приходят запросы и каким образом (через какой патерн) они формируются.

Более того, можно с одной строкой подключения (т.е. один SQL-Server + одна БД + одни и те же права), создать несколько разных соединений и использовать их параллельно или последовательно, синхронно или асинхронно.
С т.зр. SQL сервера нет никаких строк подключения - а есть СОЕДИНЕНИЕ,которое он (сервер) понимает как "сессию" (это не совсем так, но чтоб было понятнее)

Опять же SQL-сервер понятия не имеет ни о каких "моделях" и тем более "классах" (это тоже не совсем верно, но для понимания основ можно считать и так). Все они служат лишь механизмом компилятора, который позволяет работать с БД не через двоичные данные, а через объекты языка. Что очень удобно и, главное, эффективно.

Добавлено через 19 минут

Сообщение от MyCyberMan а в EF проще, разве это единственная причина чтобы использовать новую технологию как средство упрощающее разработку

Нет. Не единственная.
В ADO.NET есть классы, позволяющие с определенной долей абстракции (абстракцией потому, что многие детали обмена с сервером выполняются провайдером) взаимодействовать с данными на сервере: извлекать их или модифицировать. Эти классы детальные, т.е. имеют более-менее узкое предназначение. И требуют явного присутствия SQL-кода.
При этом наличие "классов" вовсе необязательно - можно работать с данными как с простыми коллекциями или даже массивами данных (структурами).
EF является "надстройкой" над ADO.NET или, как иногда говорят, вторым уровнем абстракции. Т.е. он во всю юзает сам ADO.NET, но предоставляет программисту упрощенный интерфейс, полностью или почти полностью избавляя его от необходимости писать руками SQL-запросы. Сущности БД: таблицы, хранимые процедуры, представления и т.д. EF отображает (маппирует - mapping) в классы, а само множество классов - в модель EDM.

Модель EDM состоит из двух основных частей:
- Декларативной - классов-юнитов, описывающих сущности БД
- Императивной - класс контекст БД, имплементирующий (реализующий) логику взоимодействия с классами.
При этом основной код оперирует моделями, а "команды" на сервер шлет используя контекст.

В итоге код приложения, работающий с БД, резко упрощается, становится интуитивно прозрачным, и весьма сокращается.
Вместо сотен строк кода ADO.NET получается несколько десятков. При этом он много надежнее и, главное, не содержит SQL-вставок.

1

Сообщение от MsGuns Сущности БД: таблицы, хранимые процедуры, представления и т.д. EF отображает (маппирует - mapping) в классы, а само множество классов - в модель EDM.

Сообщение от MsGuns В итоге код приложения, работающий с БД, резко упрощается, становится интуитивно прозрачным, и весьма сокращается.

Если я правильно понял под сокращением кода здесь подразумевается именно, осутствие необходимости заводить код классов руками, но не само по себе уменьшение объема кода?

Добавлено через 11 минут
С другой строны если я правильно понимаю, классам в EF противопоставляются атрибуты таблиц источника в ADO.NET, но в ADO.NET мы не создаем атрибуты как таковые в приложении, поэтому о сокращении работы программиста по сравнению с автогенерируемым кодом классов говорить нельзя. Мы лишь обращаемся к ним с целью получить или внести информацию. Но тогда вся надстройка EF это по сути более человечный вариант для работы с БД.

0

Сообщение от MyCyberMan Если я правильно понял под сокращением кода здесь подразумевается именно, осутствие необходимости заводить код классов руками, но не само по себе уменьшение объема кода?

Не правильно понял.

Код самого класса-сущности почти не зависит от того, как он был получен. Он зависит только от кол-ва полей таблицы БД, наложенных на нее ограничений, наличия первичных и foreign-ключей. А с помощью какого патерна он был сформирован - по барабану.

Добавлено через 11 минут

Сообщение от MyCyberMan С другой строны если я правильно понимаю, классам в EF противопоставляются атрибуты таблиц источника в ADO.NET, но в ADO.NET мы не создаем атрибуты как таковые в приложении, а лишь обращаемся к ним с целью получить или внести информацию. Но тогда вся надстройка EF это по сути более человечный вариант для работы с БД.

При использовании патерна ADO.NET (любой вариант, от OLEDBClient до OracleClient) используется "нативный" SQL, т.е. код запроса на языке SQL того стандарта, который понятен SQL-серверу. Для MS SQL Server - это TSQL, для ORACLE - PL/SQL, для других - их "клоны".
На "выходе" получаем некий датасет, типизируемый как некая "коллекция" однотипных элементов - не классов. Для того, чтобы удобно было работать с этими элементами как с экземплярами класса, необходимо делать явное приведение типа.
Это, конечно, загромождает код, делая его плохо читабельным. Опять же надо где-то помещать декларацию этого класса.
Когда проект растет, то все это в совокупности (громоздкий код + куча малопонятных классов в разных папках проекта) превращает это проект в монстра.
Использование любой ORM (в т.ч. IF) позволяет структурировать код в строгом соответствии с SOLID.

Что такое

Сообщение от MyCyberMan атрибуты таблиц источника

?
Имеется в виду метаданные сервера или еще что-то ?

Добавлено через 10 минут
При выборе паттерна важно четко знать:

1. БД уже создана ранее, там есть реальные данные, используется юзерами в данный момент. Какой-то модели ORM для этой БД нет или о ней ничего неизвестно. Доступен ли SQL - сервер в нужном объеме прав.

2. БД нет. Она создается "под проект".

В первом случае, особенно если нет нужных прав на сервере, я бы безусловно (хотя Usaga, несомненно, возразит использовал Database first.

Во-втором, наверное, Code/Model First, особенно если нет нужных знаний в соотв. стандарте (диалекте) SQL.

1

Сообщение от MsGuns Это, конечно, загромождает код, делая его плохо читабельным. Опять же надо где-то помещать декларацию этого класса. Когда проект растет, то все это в совокупности (громоздкий код + куча малопонятных классов в разных папках проекта) превращает это проект в монстра.

Согласен, вы имеете ввиду что EF позволяет писать более читабельный код. Но что касается сокращений в плане доступа к тем или иным данным, то большой разницы не вижу. Возможно есть какие-то упрощения в плане параметризации запросов или приведения типов?

Сообщение от MsGuns Что такое Цитата Сообщение от MyCyberMan Посмотреть сообщение атрибуты таблиц источника ? Имеется в виду метаданные сервера или еще что-то ?

Имел ввиду столбцы, строки таблиц с их содержимым, тк поля класса в данном случае эквивалентны столбцам таблицы

0

Сообщение от MyCyberMan Согласен, вы имеете ввиду что EF позволяет писать более читабельный код.

Да нет же. EF, как и любая ORM, дает лишь механизм, с помощью которого можно писать мало кода. Плюс избавляет от необходимости писать SQL-запросы. Вот и все. Можно этим пользоваться, а можно и не пользоваться.
Вот есть БД с одной таблицей. И есть задача- выбрать из этой таблицы данные по разным критериям, посчитать по ним что-то, и потом сгруппировать и подитожить по группам и в целом. Т.е. алгоритм из нескольких шагов, в результате какой-то НД, из которого затем получается отчет. EF даст только одну модель - класс таблицы. И методы, инкапсулированные в классе DBSet для работы с этим классом (таблицей) - выборка, изменение, удаление, вставка единичных записей.
С помощью этих методов нельзя сделать правку более одной записи, а также нелинейную выборку - для всего этого, как и для упомянутого выше отчета, надо писать свой код.
Или на C# и тогда появляются всякие репозитории и куча всяких методов, созданных вручную с использование linq или даже ADO.NET.
Или создать на сервере хранимки, которые все это будут делать, а с помощью EF их промапировать на модель и тогда необходимости в ручном коде не будет.

Т.е. EF лишь предоставляет технику, не более. Как ею пользоваться, решает программист. Вон, в соседней ветке Usaga по этому поводу слегка поспорил с freeba И он прав на 100%, когда утверждает, что сам EF весьма сомнителен, т.к. все равно приходится писать кучу кода "ручками" и при условии, что на сервере бизнес-логика не трогается.

Сообщение от MyCyberMan Возможно есть какие-то упрощения в плане параметризации запросов или приведения типов?

Не надо путать "параметризированные запросы" с методами контекста с параметрами. Это совсем не одно и то же.

Сообщение от MyCyberMan к поля класса в данном случае эквивалентны столбцам таблицы

Увы, но это не так. Поля класса соответствуют свойствам "сущностей". А те могут вообще не указывать ни на какую таблицу, а быть например отображением НД как результата SP или UDF. Или вьюшкой.
Кроме того, в общем случае модель EF может не учитывать некоторые важные детали реальных колонок реальных таблиц БД. Например, уникальность (Unique).
Т.е. утверждение, что класс модели всегда строго = таблице БД, ошибочно.

Как доказательство - типичный случай.
Была таблица на сервере с полями Pole1, Pole2. Таблица была отмаппирована в модель EF. И все работало.
Затем админ изменил таблицу, добавив в нее поле Pole3. Все будет опять работать ! Правда, это новое поле будет игнорироваться. А если админ в это поле дописал not null, то любая попытка добавить или изменить запись в проекте приведет к серверному исключению !
Для исправления ситуации надо перемапировать эту таблицу, получить новый класс и сделать соответствующие правки в коде.

Добавлено через 26 минут
Вот, на мой взгляд, очень хороший пример.
Есть таблица в БД. Например, телефонный справочник DIRPHONES с полями id, phone, Fam, Nam, Nam2, City, Street, House, Quarter

Задача - на клиенте (браузере) показать этот справочник в виде листаемого постранично (Paging) грида.

Во-первых, дабы избавить код от лишней логики, мы извлекаем не таблицу, а НД, содержащий "колонки": id, phone, FIO и Adres, готовые к "укладке" в грид. Уже получаем несоответствие ! Зачем в таком случае класс "Таблица" ? А он нужен только для получения возможности внесения правок.

Как это выглядит в EF ?
С таблицей все ясно. Есть класс модели DIRPHONES = таблице БД и класс DBSet<DIRPHONES> в контексте, через который можно вносить в таблицу БД единичные правки (insert/delete/update).
А как быть с набором данных ?
Ведь нужна: во-первых модель для строгой типизации Представления (MVC), во-вторых метод получения этого самого НД.
Откуда взять и то, и другое ?

Есть два метода:
1. Cоздать и класс, и метод ручками. (Code First). Класс добавляется в папку Model, но не в папку edmx !!! Метод добавляется в Репозиторий (который для этого и создается) и тоже не в edmx !
В этом случае SQL-сервер понятия не имеет о том, что мы добавили чего-то в модель - он просто будет отрабатывать запрос, который будет присылать ему наш метод. Как мы этот метод забабахаем: LINQ, FROM, ADO.NET методом - ему безразлично - ведь он получить "чистый" SQL.

2. Добавить в БД на сервере UDF с простым запросом типа

и отмапировать эту UDF в модель.

Теперь EF добавит нам и класс, и метод контекста. И ничего придумывать не нужно - добавить лишь строчку в метод контроллера - и все !

Это что касается модели. Но как же организовать собственно пагинацию ?

Добавлено через 23 минуты
А теперь самое интересное - пагинация !

Вот ее-то можно организовать 4-мя способами !
1. На клиенте (JavaScript)
2. На Сервере (в нашем приложении) при создании разметки
3. На Сервере (в нашем приложении) "обрезая" выборку до требуемой страницы с помощью, например LINQ
4. На Sql-сервере, посылая в написанную (и соответствующим образом исправленную) UDF дополнительные параметры:
кол-во строк на листе, № нужного листа и колонку сортировки.

Разберем их по очереди, с плюсами и минусами

1. JavaScript

В разметку попадают все записи справочника подряд. Написанный код JS либо "прячет" лишние записи, либо "вырезает" страницу из разметки и кладет ее в другую разметку, которую и показывает, пряча "настоящий" справочник.
Это же код "организует" и собственно "листание", добавляя в разметку кнопки и обрабатывая нажатие на них.

Плюс - Логика как в нашем приложении, так и на SQL-сервере никоим образом не "страдает". Приложение посылает на SQL-сервер "полноценный запрос", его ретранслирует в разметку и отсылает браузеру. Никаких проблем !
Минус. Увы, пересылка тысяч записей по сети (а в случае с удаленным SQL-сервером - ДВА раза !), "перегруз", а соответственно и "тормоза" на браузере, особенно если это мобила или старенький ПК.
Вывод: НЕ ГОДИТСЯ !

2. Создание разметки.
Логика как на SQL-сервере, так и в контексте нашей Модели не "страдает".
"Обрезка" страницы выполняется Rasor при компоновке разметки. Тут уже надо знать номер требуемой страницы и кол-во строк на странице, т.е. добавляем поддержку этих дополнительных параметров как в представление, так и в логику контроллера приложения.

Плюс - Опять же не трогаем Модель и SQL-сервер ! Вместо тысяч записей на браузер отправляется только 10-20 (кол-во строк на странице). Никакой JS-обработки и тормозов на условной "мобиле".
Минус - Нагружаем контроллер и представление дополнительной логикой, связанной с параметрами, а также - все эти тысячи записей справочника благополучно "шелестят" от SQL-сервера к Web-серверу (нашему приложению)

Учитывая, что при листании каждой страницы мы по полной грузим SQL-сервер, а также локальную сеть, сомнительно !

1

Сообщение от MsGuns В первом случае, особенно если нет нужных прав на сервере, я бы безусловно (хотя Usaga, несомненно, возразит использовал Database first.

Не совсем понял. Причём тут права на сервере?..

1

3. Обрезка дополнительной логикой в репозитории.
Параметры остаются в силе, метод контроллера передает их не в контекст Модели, а в репозиторий. Код метода репозитория обращается к контексту, но при это берет только нужные строки с помощью конструкции LINQ, куда подставляет принятые значения параметров. Где происходит собственно обрезка ? Мне кажется, что SQL-сервер отправляет все записи справочника, а EF их уже режет. Хотя не уверен.

Плюс - нет кода на браузере, нет "лишней" логики в Представлении, нет "тормозов" (Rasor работает существенно медленнее c#, не говоря уже про SQL-сервер).
Минус - увы, также лишняя нагрузка на сеть и на Web-сервер (полученные из БД записи надо куда-то сложить, а это ОП)
Также требуется "городить" огород, засовывая значения параметров в LINQ. Ну и опять же лишний "слой" - Репозиторий, что делает общую логику менее прозрачной.

4. Обрезка на SQL-сервере.
UDF, конечно, немного усложнится (OFFSET), а если еще и с учетом сортировки, то усложнится существенно (скорее всего придется писать вместо UDF хранимку).

Минус - написание SQL и добавление в БД новой UDF/SP, для чего должны быть права. Перемапирование модели с добавлением не UDF, а SP.
Плюсы - нет кода на браузере, нет лишнего кода в Представлении, нет Репозитория и "танцев" с LINQ. Контроллер получает параметры из HTTP и просто передает их с некоторой модификацией (№ листа -1 или +1) прямо в контекст. По сети в обоих случаях ходят только 10-20 записей, все "летает".

Добавлено через 3 минуты

Сообщение от Usaga Не совсем понял. Причём тут права на сервере?..

Если нет возможности создавать SP/UDF. Сервер просто недоступен - нет прав. Вы слышали про "Парус" ? Так вот, доступ к ORACLE в нем для филиалов корпорации ограничен. Ну вот такая ситуация

1

Почитал Ваш комментарий и сформировал несколько вопросов ответы на которые на мой взгляд могли бы детальнее прояснить Вашу точку зрения. В данном отрывке

Сообщение от MsGuns Да нет же. EF, как и любая ORM, дает лишь механизм, с помощью которого можно писать мало кода. Плюс избавляет от необходимости писать SQL-запросы. Вот и все. Можно этим пользоваться, а можно и не пользоваться. Вот есть БД с одной таблицей. И есть задача- выбрать из этой таблицы данные по разным критериям, посчитать по ним что-то, и потом сгруппировать и подитожить по группам и в целом. Т.е. алгоритм из нескольких шагов, в результате какой-то НД, из которого затем получается отчет. EF даст только одну модель - класс таблицы. И методы, инкапсулированные в классе DBSet для работы с этим классом (таблицей) - выборка, изменение, удаление, вставка единичных записей. С помощью этих методов нельзя сделать правку более одной записи, а также нелинейную выборку - для всего этого, как и для упомянутого выше отчета, надо писать свой код. Или на C# и тогда появляются всякие репозитории и куча всяких методов, созданных вручную с использование linq или даже ADO.NET. Или создать на сервере хранимки, которые все это будут делать, а с помощью EF их промапировать на модель и тогда необходимости в ручном коде не будет. Т.е. EF лишь предоставляет технику, не более. Как ею пользоваться, решает программист. Вон, в соседней ветке Usaga по этому поводу слегка поспорил с freeba И он прав на 100%, когда утверждает, что сам EF весьма сомнителен, т.к. все равно приходится писать кучу кода "ручками" и при условии, что на сервере бизнес-логика не трогается.

Вопросы
1)

Сообщение от MsGuns НД

- что это значит?

2)

Сообщение от MsGuns Или на C# и тогда появляются всякие репозитории и куча всяких методов, созданных вручную с использование linq или даже ADO.NET. Или создать на сервере хранимки, которые все это будут делать, а с помощью EF их промапировать на модель и тогда необходимости в ручном коде не будет.

- То есть Вы имеете ввиду, что работа с хранимыми процедурами в ADO.NET намного сложнее чем в EF?

3)

Сообщение от MsGuns появляются всякие репозитории и куча всяких методов

- а как обстоит дело с EF там не нужжно создавать репозитории и методы?

4)

Сообщение от MsGuns с помощью EF их промаппировать на модель и тогда необходимости в ручном коде не будет.

- Вы имеете ввиду, что маппирование позволит автоматически изменять модель, а измененная модель позволит автоматически изменять код?

5)

Сообщение от MsGuns при условии, что на сервере бизнес-логика не трогается

- Почему именно при таком условии?

0

НД - Набор данных или DataSet.

Сообщение от MyCyberMan То есть Вы имеете ввиду, что работа с хранимыми процедурами в ADO.NET намного сложнее чем в EF?

Не намного, но посложнее, т.к. придется кодом формировать параметры SP/UDF. На каждый параметр как мин. одна строчка кода.
Для метода контекста, возвращающего НД как результат ХП, это делать не надо - параметры передаются обычным способом, а уже EF "заворачивает" их в ХП.

Сообщение от MyCyberMan а как обстоит дело с EF там не нужжно создавать репозитории и методы?

Если хватает того, что дает EF, то никаких репозиториев не нужно. Также, как и дополнительных классов Модели.

А вот если не дает..

Сообщение от MyCyberMan Вы имеете ввиду, что маппирование позволит автоматически изменять модель, а измененная модель позволит автоматически изменять код?

Мапирование/Перемапирование нужно для того, что EF пополнил или изменил Модель так, чтобы ее сущности соответствовали объектам метаданных БД SQL-сервера.
Типа синхронизации той части физической БД, которую использует приложение, с Моделью БД в приложении EF.

Если метаданные БД не менялась с момента последней рефлексии (мапирования) на Модель, этого делать не нужно.

Сообщение от MyCyberMan Почему именно при таком условии?

Потому что если есть возможность написать некоторый алгоритм взаимодействия с БД, то есть выбор:
писать его на шарпе "ручками" либо создать соотв. Stored Proc/ User Defined Function где-нибудь в SQL Management Studio и добавить ее в бизнес-логику сервера SQL в нашей БД.

Если нет такой возможности (незнание SQL, нет нужных прав на БД, корпоративное табу, приказ начальника и т.д.),
то выбора нет и надо писать код в проекте.

Добавлено через 17 минут

Сообщение от MyCyberMan а как обстоит дело с EF там не нужжно создавать репозитории и методы?

Фухх.. Еще раз: Если Модель, поставляемая EF, полностью покрывает потребности приложения, никаких репозиториев и дополнительных классов не нужно.

Но бывает так, что надо работать с некоторыми данными, которые EF не дает. Ну нет в БД такой таблицы/View/SP/UDF. Нету !

А надо ! Я выше приводил пример, когда из телефонной книги (соотв.таблицы БД), надо выбрать информацию, но структурированную иначе, чем она хранится в таблице БД. Для этого пишется запрос. И если этот запрос формируется в приложении, то приложение и должно позаботиться о том, чтобы результат был отражен в Модели классом, а также был метод, отвечающий за посылку такого запроса на SQL-сервер и получение от него соотв. результата (в виде добавленной Модели - класса). Причем важно, что и посылка запроса, и получения результата пройдут "мимо" EF.
Для этого-то и создается как доп.класс, так и Репозиторий в папке Model.

Обычно помимо папки.edmx в папке Models лежит еще один или более юнитов xxx.cs, представляющих дополнительные классы Модели, а также файл репозитория yyy.cs, имплементирующий методы для всех дополнительных классов.

Грубо говоря, вся модель делится на 2 части
1. Модель EF. Получается автоматически. В код лазить нельзя !
2. Модель-дополнение, реализующая ту часть логики, которую не обеспечивает EF. Код "ручной".

Обе части существуют независимо друг от друга, хотя методы репозитория вполне могут обращаться к методам контекста и юзать классы Модели EF (Но ни в коем случае не наоборот !)

В приложении можно обращаться к любой из частей в зависимости от необходимости.

Добавлено через 24 минуты
Вот простой наглядный пример:

В БД есть три таблицы:

-- Таблица "Справочник клиентов"
CREATE TABLE CUSTOMERS (
Cid INT IDENTITY(1,1) PRIMARY KEY, -- Id клиента
CName VARCHAR(MAX) NOT NULL, -- Имя (ФИО физлица или наименование юр.лица)
CLegFlag INT NOT NULL, -- 1 если юр.лицо, 0 - физ.лицо
CPhone VARCHAR(16) NULL -- Телефон связи
)

-- Таблица "Справочник товара"
CREATE TABLE GOODS (
Gid INT IDENTITY(1,1) PRIMARY KEY, -- Id товара
GName VARCHAR(MAX) NOT NULL, -- Наименование товара
GPrice DECIMAL(16,2) NOT NULL, -- Цена товара
)

-- Таблица "Журнал покупок"
CREATE TABLE PURCHASES(
PId INT IDENTITY(1,1) PRIMARY KEY, -- Id покупки
PDate DATETIME NOT NULL, -- Время покупки
PCid INT REFERENCES CUSTOMERS(CId) NOT NULL, -- Ссылка на покупателя
PGId INT REFERENCES CUSTOMERS(CId) NOT NULL, -- Ссылка на товар
PQnt INT NOT NULL, -- Кол-во товара
PSumma DECIMAL(19,2), -- Сумма за товар
PCheck INT -- 1 если оплачен, 0 - нет
)

Добавлено через 11 минут
Задача

Написать приложение для просмотра журнала покупок в следующих ракурсах:

1) Информация по всем покупателям и всем товарам,
2) Информация по выбранному покупателю,
3) Информация по выбранному товару

с возможностью задавать период: за месяц, за квартал, за год, за произвольный диапазон дат

предусмотреть возможность сортировки по датам, суммам, товару и покупателю

Дополнительно:

Вывести сводную таблицу в одном из видов на выбор пользователя:
1) Покупатель - товар - общая сумма
2) Покупатель - общая сумма по всем товарам
3) Товар - общая сумма по всем покупателям.
Сортировка по покупателю или товару или сумме (по убыванию)

Добавлено через 5 минут
Создаем приложение и сразу добавляем Модель EDM:
- Соединяемся с SQL-сервером,
- Выбираем нашу БД из предложенного списка,
- Получаем строку соединения и имя пространства имен для Модели EDM
- В окне объектов БД ставим галочку на "Таблицы".
- Жмем Ок

Получаем Модель, состоящую из трех файлов-классов Модели: CUSTOMER.cs, GOODS.cs и PURCHASES.cs,
А также контекст с тремя классами DBSet.

И тут мы видим, что ни одна из этих моделей не совпадает с теми, которые нам нужны для отображения в приложении.
Вот досада и что делать ?

Добавлено через 3 минуты
Забыл добавить еще один немаловажный пункт в Задание:

Возможность раздельного учета оплаченных и неоплаченных товаров.

0