Да, спасибо, что-то подобное я уже читал, хоть и не про .NET.
Таким образом, сложные вещи делать через ORM не надо, а простые... Зачем тогда вообще ORM? Опять же, может, в обсуждаемых тут EF и NHibernate это не так, но в Django/RoR накладываются довольно жёсткие ограничения даже на именование таблиц в БД, что конфликтует с принятыми названиями у меня в голове, например Да, их можно обойти, но тогда синтаксис работы с ORM будет многословней SQL-запроса.
Здравствуйте, Ringin, Вы писали:
R>А вот надо мне например вывести пользователю все таблицы базы данных, прочитать констрейнты и показать связи, как это сделать?
Создаете папочку с моделью данных, делаете свой objectcontext, и все.
Такая штука там очень легко делается.
Там где нужно создавать объектную модель данных я абсолютно за EF.
Хороший инструмент, запросы проходят быстро, не знаю кто и как писал но у меня за 2 секунды грузились 10к очень сложных объектов.
Создание логики и архитектуры с помощью него тоже проходит быстро.
Хранимки и прочий sql предполагается использовать для более сложных операций поиска,создания временных таблиц и так далее.
Здравствуйте, gandjustas, Вы писали:
G>А ты давно пробовал использовать ef на практике? После допила migrtions и передачи в OpenSource версия 6.0 получилась очень достойная.
Ничего там достойного, те же косяки в тех же местах. Там врожденная проблема, которая заключается в неадекватности идеи на которой весь проект строился, плюс не очень удачная реализация, которая не позволяет избавиться от наследия прошлого не переписав большую часть кода.
Я об этом утверждал много лет назад, в том числе и в этом топике. Наконец-то они и сами это признали...
Мое любимое место:
As we look at what we want to achieve in EF7 we’ve had to take a realistic look at our current code base.
<….>
As a result, there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons
Здравствуйте, Dair, Вы писали:
D>Я как-то отстал от жизни, зачем пользоваться ORM вообще?
Давай на конкретных примерах. Перепиши с идентичным поведением и полным сохранением контроля компилятора этот примитивный код без ORM:
using (var db = new XxxDB())
{
var model =
db
.Messages
.Where(m => m.ID == id && m.Forum.ReadLevel <= Account.AccessLevel)
.Select(
m =>
new MessageModel
{
ID = id,
ForumShortName = m.Forum.ShortName,
CreatedOn = m.CreatedOn,
Subject = m.Subject,
Text = FormatMessageBody(id, m.Account.Origin)
})
.FirstOrDefault();
return model == null ? ErrorMessageBox("Сообщение не найдено") : View(model);
}
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>А ты давно пробовал использовать ef на практике? После допила migrtions и передачи в OpenSource версия 6.0 получилась очень достойная. IB>Ничего там достойного, те же косяки в тех же местах. Там врожденная проблема, которая заключается в неадекватности идеи на которой весь проект строился, плюс не очень удачная реализация, которая не позволяет избавиться от наследия прошлого не переписав большую часть кода.
А конкретнее? Сообщение выглядит как набор лозунгов.
Здравствуйте, gandjustas, Вы писали:
G>Че-то ты путаешь. В EF6 схему можно сделать любую. Если билдера не хватит, то просто напиши DDL команды руками. Скорее всего ты говоришь EF4, где схема генерится по модели и влиять но это нельзя.
Я имел в виду то, что товарищи, вооруженные EF'ом, очень часто жалуются на то, какие схемы (вполне легальные с точки зрения реляционной теории) мы используем. Часто просят, например, сделать некоторые поля nullable'ными. NHibernate всё, что ни сочиняли, проглатывает.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, gandjustas, Вы писали:
G>Да ладно? Напомни когда в NHibernate появились: G>1) Асинхронное выполнение запросов, чтобы await работало
Внимание, вопрос. Что будет в этом случае:
var dbContext = new DbContext();
var something = await dbContext.Foo.FirstOrDefaultAsync(e => e.Id == 1);
var morething = await dbContext.Foo.FirstOrDefaultAsync(e => e.Id == 2);
Правильно, получишь по пальцам. Так что можно считать, что async в EF появилась по недоразумению и ничего особенного из себя не представляет. Загугли NHibernate Futures, которые, хоть и не async, а все равно круты.
G>2) Готовая функция или расширение вроде https://github.com/loresoft/EntityFramework.Extended, которые позволяют делать массовые обновления и удаления
HQL умеет.
G>3) Локальный кеш в виде ObservableCollection для того чтобы байндить сеты напрямую в UI, а не писать 100500 мапперов
Снова фича из нипоймиоткуда. В NHibernate такого нет, но какое отношение это имеет к ORM'ам, которые мы обсуждаем?
G>CI сервер не решает проблем рассинхрона моедли и приложения. А миграции, как ни удивительно, решают.
Что будет, если по каким-то причинам (например, не удастся создать уникальный индекс) миграции не накатятся? В твоем случае получим неработоспособное приложение. В случае с CI-сервером всегда есть возможность восстановить БД из предварительно сделанного бэкапа.
G>Почему это неправильно? В 90% случаев применения ORM в БД никто кроме приложения не ходит, так что вполне нормальный сценарий.
Это неправильно. PLOP.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, gandjustas, Вы писали:
G>А конкретнее? Сообщение выглядит как набор лозунгов.
Ну отмотай выше этот же топик, я устал уже в восьмой раз все озвучивать.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>А конкретнее? Сообщение выглядит как набор лозунгов. IB>Ну отмотай выше этот же топик, я устал уже в восьмой раз все озвучивать.
Все что ты озвучивал конкретное касалось старых версий. Про "неадекватность идеи" как не было ответа, так и нет.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, gandjustas, Вы писали:
G>>Да ладно? Напомни когда в NHibernate появились: G>>1) Асинхронное выполнение запросов, чтобы await работало
Н>Внимание, вопрос. Что будет в этом случае:
Н>
Н>Так что можно считать, что async в EF появилась по недоразумению и ничего особенного из себя не представляет.
Прекрасно работает, если ты не умеешь использовать, то это твои проблемы. EF тут не при чем.
Н>Загугли NHibernate Futures, которые, хоть и не async, а все равно круты.
Фигня там никому не нужная, а не фичи.
G>>2) Готовая функция или расширение вроде https://github.com/loresoft/EntityFramework.Extended, которые позволяют делать массовые обновления и удаления Н>HQL умеет.
HQL это текст, а расширение позволяет писать код, который, например, спокойно переживает рефакторинг переименования, а миграции спокойно обновляют базу.
G>>3) Локальный кеш в виде ObservableCollection для того чтобы байндить сеты напрямую в UI, а не писать 100500 мапперов Н>Снова фича из нипоймиоткуда. В NHibernate такого нет, но какое отношение это имеет к ORM'ам, которые мы обсуждаем?
Потому что есть сценарии, в которых используются ORM наиболее активно — десктопные приложения, работающие с базой и веб-сайты с отображением модели 1-в-1 в базу. Все остальные сценарии для ОРМ встречаются на два порядка реже.
EF отлично реализует фичи для обоих сценариев (на данный момент круче всех в .NET), но совершенно ими не ограничивается.
G>>CI сервер не решает проблем рассинхрона моедли и приложения. А миграции, как ни удивительно, решают.
Н>Что будет, если по каким-то причинам (например, не удастся создать уникальный индекс) миграции не накатятся? В твоем случае получим неработоспособное приложение. В случае с CI-сервером всегда есть возможность восстановить БД из предварительно сделанного бэкапа.
Не говори чушь, DDL транзакции придумали давно, если база не может обновится то просто упадет приложение при старте.
Твое представление о EF застряло на уровне 2010 года, открой глаза, на дворе 2014. Два мажорных релиза было за это время.
G>>Почему это неправильно? В 90% случаев применения ORM в БД никто кроме приложения не ходит, так что вполне нормальный сценарий. Н>Это неправильно. PLOP.
Аргумент!
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, gandjustas, Вы писали:
G>>Че-то ты путаешь. В EF6 схему можно сделать любую. Если билдера не хватит, то просто напиши DDL команды руками. Скорее всего ты говоришь EF4, где схема генерится по модели и влиять но это нельзя.
Н>Я имел в виду то, что товарищи, вооруженные EF'ом, очень часто жалуются на то, какие схемы (вполне легальные с точки зрения реляционной теории) мы используем. Часто просят, например, сделать некоторые поля nullable'ными. NHibernate всё, что ни сочиняли, проглатывает.
А в чем проблема в EF написать так:
public class TestEntites : DbContext
{
public DbSet<Foo> Foo { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Foo>().Property(e => e.Data).IsOptional();
base.OnModelCreating(modelBuilder);
}
}
при этом:
public class Foo
{
public int Id { get; set; }
[Required]
public string Data { get; set; }
}
Тогда валидация asp.net на клиенте и сервере не пропустит null в поле Data, а в базе будет Nullable поле. При желании можно еще и валидацию обязательного поля сделать при сохранении в базу.
Судя по твоим постам ты EF последний раз видел 5 лет назад.
Здравствуйте, gandjustas, Вы писали:
G>Покажи как это сделать склейкой строк.
public static QFragment GoldCutomer(Param<decimal> threshold)
{
return new {threshold}.QFragment(@"
(SELECT SUM(Quantity * UnitPrice)
FROM [Order Details] od
JOIN Orders o ON od.OrderID = o.OrderID
WHERE o.CustomerID = c.CustomerID
) > @threshold");
}
По поводу Dapper-а и LINQ. Вот разработчик stackoverflow детально описывает real world код.
700ms только на то, чтобы сформировать строку запроса (до отправки в СУБД).... 700ms ... 700ms ...
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>Покажи как это сделать склейкой строк. AP>
AP> public static QFragment GoldCutomer(Param<decimal> threshold)
AP> {
AP> return new {threshold}.QFragment(@"
AP>(SELECT SUM(Quantity * UnitPrice)
AP> FROM [Order Details] od
AP> JOIN Orders o ON od.OrderID = o.OrderID
AP> WHERE o.CustomerID = c.CustomerID
AP>) > @threshold");
AP> }
AP>
Пфф, QFragmet не типизирован. Нет никаких гарантий, что этот фрагмент будет присоединен к выборке из Customer. Более того, нет гарантии что алиас для таблицы Customer будет именно "c". Про проверки при компиляции вообще молчу.
Здравствуйте, gandjustas, Вы писали:
G>Пфф, QFragmet не типизирован. Нет никаких гарантий, что этот фрагмент будет присоединен к выборке из Customer. Более того, нет гарантии что алиас для таблицы Customer будет именно "c". Про проверки при компиляции вообще молчу.
Ты вообще читаешь? Третий раз повторяю, есть автоматическая проверка всех запросов.
Да, их можно обойти, но тогда синтаксис работы с ORM будет многословней SQL-запроса.
Мы уже победили, просто это еще не так заметно...
