Comments 15
Что то POCO ( plain old class objects) тут и не пахнет, все эти аттрибуты и navigation property засоряют модель. Пример работы с POCO — PetaPoco, берем любой класс и в него маппим результат SQL запроса. И не надо fluent городить — SQL для общения с базой — самый правильный и родной вариант.
т.е. вам от ORM необходим только маппинг?
От Object-Relational Mapper — да, мне необходим именно маппер, потому что все остальное оно делает хуже чем нативный интерфейс.
Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
Да, у меня бы тоже язык не повернулся назвать класс с кучей библиотечно-зависимых атрбиутов POCO.
Примерно год назад начали наблюдать LicenceException в логе после обновления на 4 версию — ввели ограничение — бесплатны только первые 10 таблиц.
По-хорошему могли хотя бы назвать коммерческий пакет по-другому чтобы не ломать код при обновлениях. В итоге перешли на Dapper, т.к. в OrmLite неизвестно что еще сломают в следующей версии.
По-хорошему могли хотя бы назвать коммерческий пакет по-другому чтобы не ломать код при обновлениях. В итоге перешли на Dapper, т.к. в OrmLite неизвестно что еще сломают в следующей версии.
А чего не поддержали отечественного производителя?
Linq2Db (бывший BLToolkit) навскидку умеет все то же самое но без лицензионных заморочек. Интересно было бы сравнить его по скорости с OrmLite
Linq2Db (бывший BLToolkit) навскидку умеет все то же самое но без лицензионных заморочек. Интересно было бы сравнить его по скорости с OrmLite
Эту библиотеку можно использовать не только под коммерческой лицензией, но и под GNU Affero General Public License.
github.com/ServiceStack/ServiceStack.OrmLite/blob/master/license.txt
github.com/ServiceStack/ServiceStack.OrmLite/blob/master/license.txt
По-моему зря не поддержали родной LINQовский naming convention. Для разработчика непривычно видеть
гораздо привычнее
Я конечно понимаю, что тема холиварная, но в .NET уже давно так. Зачем городить свой огород?
db.Select<Product>(q => q.UnitPrice > 10)
гораздо привычнее
db.Products.Where(q => q.UnitPrice > 10)
Я конечно понимаю, что тема холиварная, но в .NET уже давно так. Зачем городить свой огород?
Entity Framework:
context.Orders.AsNoTracking().FirstOrDefault(order => order.Id == id);
Какой будет результат, если использовать EF грамотно?
context.Orders.Find(id);
Как вам должно быть известно, Find сначала ищет в контексте по Id, если не найдет — обращается к БД. Вот только в данном примере я сравнивал скорости отдельных и друг от друга независимых запросов к БД без участия кэширования. Следствие: в контексте в принципе не может быть объекта с тем же Id (создается контекст на запрос), поэтому использование Find бессмысленно.
Грамотно говоря, для большого графа объектов в контексте, использование Find может быть даже вредно, если заранее известно, что нужного объекта в контексте нет — эффективнее сразу использовать прямой запрос к БД.
Грамотно говоря, для большого графа объектов в контексте, использование Find может быть даже вредно, если заранее известно, что нужного объекта в контексте нет — эффективнее сразу использовать прямой запрос к БД.
Sign up to leave a comment.
Обзор ServiceStack.OrmLite — micro-ORM для .NET