Вообще, существуют нормальные туториалы по CRUD с использованием Entity Framework для связанных данных? Причём для различных видов связей: 1-1, 1-*, *-*.

Везде либо

детский сад без отношений , где запрашивают один объект из БД и обновляют его поля,

либо замороченная хрень , пересыпання кучей АСП.НЕТа и прочего мусорного кода, где, опять же, никаких отношений,

либо разбирается только один случай , но при этом непонятно, как он избавился от того, что EF перестаёт генерить *-* через навигационные свойства-коллеции, а оставляет таблицу связей и создаёт для неё сущность; code first не предлагать, также, как и работать с дизайнером EF - у меня есть уже готовая БД и с ней я должен работать,

либо CRUD на хранимых процедурах (нах они мне сдались - мне код нужен, как на C# это же сделать с помощью объектов ORM, а не хранимых процедур),

либо в подробностях и со смаком рассказывают, как надо читать данные , при этом пересыпают всё всякими ленивыми и жадными загрузками, а как, плять, CRUD делать с отношениями - никуя!,

либо как работать с Local , но без CRUDа со связями.


Ребята, я реально заипался искать, как же работать с этим факнутым EF! Я перечитал все, имеющие хоть отдалённое отношение к CRUD темы на http://msdn.microsoft.com/en-us/data/ee712907 . Результат - выше. Я работаю с EF, как будто бы его у меня нет и есть только тупое объектно-реляционное отображение, чтобы я мог обращаться к таблицам как к сущностям. Т. е. я ручками гружу все связанные данные отдельным запросом, обновляю всё по-отдельности, удаляю тоже по-отдельности. Что такое навигационные свойства и как их использовать для CRUD я не знаю. Я вот только прочитал, как грузить данные с ними, а дальше - правки и удаления - непонятно ничего. Я выше примеры привёл, что есть всё, что угодно, кроме самого простого и нужного - CRUD для разных случаев связей.

Я не понимаю, как вы или кто другой становитесь профи в работе с EF - туториалов же нормальных нифига нет! Или может, я что-то пропустил? Покажите, пожалуйста, где нормально объяснено, как делать CRUD с отношениями, без пересыпок этими АСП.НЕТами (ну реально непонятно, где там собственно обновление идёт со связями... по-моему, там всё без связей) и без половины статьи про ленивые и жадные загрузки, вместо собственно CRUDа.

EDUARD SAPOTSKI,

Так главное, где нормальные мануалы по этой технологии, чтобы её типазнать? Все мануалы либо на code first / designer first заточены, либо простые и частные случаи разбирают. При этом, чтобы составить для себя полную картину "CRUD для всех видов отношений", надо сотню этих статей с частными случаями перепахать (и всё равно всех примеров не найдёшь - придётся спрашивать людей в Интернете) - чем я сейчас и занимаюсь. Я не понимаю, может, создатели EF считают свой продукт настолько понятным даже школьникам, что никаких нормальных мануалов писать не надо?

Я уже не говорю, как этот EF с CRUD для различных связей связать с MVVM. Доходит до маразма - создатели EF говорят, что их модели-сущности поддерживают привязки и сами. Т. е. то, что у меня есть или будет структура MVVM - им пофиг. Вот и получается, что их сущности с поддержкой привязок годятся только для поделок на коленке, а в нормальное приложение с кучей слоёв как это интегрировать - думайте сами. Максимум, что я видел - "лучше реализовать репозиторий". Только для этого "лучше" поддержка привязок от EF тогда нафиг получается не нужна, ибо это уже вотчина моделей представления.

Ладно, изучаю дальше...

авторлибо разбирается только один случай, но при этом непонятно, как он избавился от того, что EF перестаёт генерить *-* через навигационные свойства-коллеции, а оставляет таблицу связей и создаёт для неё сущность;
Разобрался. Если у таблицы связи (мы говорим об отношении *-*) есть собственный PK, являющийся идентификатором, то EF генерит отдельную сущность для этой таблицы. Если идентификатора нет, то не генерит. При этом во втором случае желательно, чтобы оба FK являлись также и PK, составляя вместе композитный ключ, иначе EF ругается чем-то типа "The table/view ''...' does not have a primary key defined. The key has been inferred and the definition was created as a read-only table/view.". Тогда первый вариант ялвяется как бы не прямым отношением *-*, а опосредованным через вспомогательную таблицу. А второй вариант - прямым, где таблица связи служит собственно только для связи и для преодоления ограничений СУБД, которые не могут иначе представить связь *-*, кроме как через третью таблицу. Зато в первом варианте можно хранить дополнительные данные в таблице связей, и в ORM'е эти данные не потеряются, т. к. для них будет собственная сущность.

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