Здравствуйте, Serginio1, Вы писали:

_>>А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.
S> Для того, что бы что то хаять нужно ознакомиться с темой?

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

_>>Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.
S> Я же тебе давал ссылки, показывал какие генерятся запросы. Ничего сомнительногог, сильно уменьшант количество лишнего кода.

Подобная функциональность очевидно тривиально (в несколько строк) добавляется практически в любую ORM. Только вот я что-то не помню такого ни в одной, из тех, что я видел (причём речь далекое не только про C++). Интересно почему... )))

_>>Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.
S> Я тебя уверяю, что нет. В 8 ке есть аналогичные запросы .
S>...
S> Есть очень интересный проект 1С++ там можно строить запросы, но доступ к навигационным свойствам нет. Приходится городить кучу левых соединений.
S>Это значительно менее читабельно, и большая возможность ошибки. А вообще основной смысл Линк для СкуЛ как раз и есть навигационные свойства.

Я же сказал, отдельные запросы, а не ручные join'ы. Т.е. допустим мы получаем полный список объектов (как раз в виде внешних ключей) из одной таблице, а потом получаем уже сами объекты из другой таблице. По одной штуке за раз и только в тот момент, когда пользователь их запросил (допустим выделил в списке).

_>>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).
S> Да ну. Не говори чушь. Синтаксис убогий, нет поддержки навигационных свойств. Нет поддержки биндинга итд.

Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

_>>Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.
S> Это относится и к ВПФ. И здесь продумано все в одном без лишних телодвижений с поддержкой Студии.

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