Сообщение Re[70]: Java vs C# vs C++ от 07.10.2015 15:56
Изменено 07.10.2015 16:38 Serginio1
Здравствуйте, alex_public, Вы писали:
_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.
_>>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.
_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.
_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)
_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.
_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.
_>>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.
_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.
_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)
_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.
Re[70]: Java vs C# vs C++
Здравствуйте, alex_public, Вы писали:
_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.
Кстати неизвестно насколько твой sqlpp11 генерирует оптимальный SQL код на сложных запросах. Я приводил результирующие SQL на нетривиальных запросах.
В своё время EF был очень далек от оптимальности. Сейчас уже достаточно близко к идеалу. Как и что генерит sqlpp11 неизвестно.
_>>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.
_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.
_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)
_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.
_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.
Кстати неизвестно насколько твой sqlpp11 генерирует оптимальный SQL код на сложных запросах. Я приводил результирующие SQL на нетривиальных запросах.
В своё время EF был очень далек от оптимальности. Сейчас уже достаточно близко к идеалу. Как и что генерит sqlpp11 неизвестно.
_>>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.
_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.
_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)
_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.