Pull to refresh

Comments 20

Лучше бы сделали достойный ORM.
EF хоть и хорош но почему все жалуются на его производительность ??
Выкинули бы Команду которая EF создавала, и поглотили бы http://www.llblgen.com/


Как до это сделали с Xamarin и Datazen !!


Что EF6 что EF7 до сих пор тормознуто.
http://ppanyukov.github.io/2015/05/20/entity-framework-7-performance.html


Да и почему то на https://www.techempower.com до сих пор нету тестов под Windows платформу !


Весь стек Asp net core должен быть производительным а не только отдача простого TXT-json файла.

Непонятно за что минусуют, все по делу. Добавлю от себя: непонятно зачем web-фреймворку orm с трэкингом состояний… это же stateless среда. От этого никакой пользы нет, только оверхэд.

Если не ошибаюсь, трэкинг в EF можно выключить.

Можно, если ничего в базу писать не будете. Лишние заморочки...

Отличная библиотека! От ее полноценного использования останавливает только наличие миграций в EF. Не знаете есть ли что-то приличное для миграций с linq2db?

Доводилось работать с FluentMigrator несколько лет назад. Но миграция в EF всё-таки лучше сделана :)
Теоретически ничего не мешает делать миграцию с помощью EF, а потом работать с данными с помощью linq2db.
Написано, что для FluentMigrator нужен Ruby о_О
Пару лет назад я участвовал в разработке ecm7migrator (форк Migrator.NET, постепенно полностью переписанный). Он имеет простой API, не завязан на ORM и покрыт тестами. Использовал мигратор в нескольких проектах с NHibernate и очень доволен. В принципе, остальные, кому рекомендовал — тоже довольны.

Сейчас делаю большой проект на .NET Core. Там использую EF, т.к. особого выбора нет. Пробовал его миграции, но не подошли, т.к. неудобно писать руками + они не умеют вести параллельно несколько «линий» версионирования (в моем проекте нужно, чтобы плагины могли создавать себе нужную структуру БД и для каждого плагина отдельно велся учет версий).

В результате портировал на .NET Core ядро ecm7migrator и модуль, поддерживающий PostgreSQL. Всё завелось легко и тесты прошли без проблем.

Посмотрите его, возможно, вам покажется удобнее остального. Я готов оказать помочь в использовании и в портировании на .NET Core модулей для поддержки других СУБД.

Можно использовать Dapper и MicroOrm.Dapper.Repositories.
Значительный прирост производительности. Конечно придется писать больше кода, чтобы все это обернуть.
Использую EF в производительных проектах исключительно для миграций.
UFO landed and left these words here
Именно для этого есть linq2db. Query decomposition там работает на ура с многочисленными плюшками оптимизации. Для меня лучше написать linq запрос который компилятором проверится и я буду спокоен, что ничего из-за изменения модели не поломал.
UFO landed and left these words here
Почему же так категорично не попробовав. Скорее всего такое мнение складывается после неудачной попытки использования EF. Как результат все бегут к Dapper, теряя все преимущества типизации.
Я такие трехэтажные linq запросы писал что дух захватывало. Все это превращалось в соптимизированный SQL.
При реализации Delete бросать NotFound не правильно. По RESTfull принципам этот тип запроса должен быть идемпотентным.
хотелось бы увидеть статью по создание авторизации для web API
Для таких внимательных как я: Это перевод — остальные статьи есть в оригинале.
Я понимаю, что это перевод в цикле статьей. Но зачем делать еще одну, в которой уже расписано как создать WebApi, когда это было сделано здесь? Показать, что можно использовать вместе с Xamarin? Так WebApi на то и API, что его может дергать любой клиент. Было бы лучше рассказать, как тот же пример отредактировать, чтобы он по разному работал для запросов с мобильного приложения и с web-приложения.
Sign up to leave a comment.