Здравствуйте, Alexander Polyakov, Вы писали:
AP>А опыт показывает, что при использовании LINQ всегда чувствуется профессиональная неловкость: блин, да, дайте мне уже самому написать SQL, который я знаю как должен выглядеть, а не заставляете меня извращаться через посредника в виде linq.
А что же ты на ассемблере не пишешь? Ты же знаешь что компьютер должен делать, зачем извращаться через посредника?
Если ты знаешь как sql должен выглядеть, то ты или ясновидящий, или запросы примитивные. Но скорее всего ты только думаешь что знаешь.
НС>Перепиши с ним.
Печатал без компиляции и без CheckAllQueries, возможны опечатки.
return Query<IMessageInfo>.New(new {id}, @"
SELECT f.ShortName ForumShortName, m.CreatedOn, m.Subject, a.Origin
FROM Message m
JOIN Forum f ON f.Id = m.ForumId
OUTER JOIN Account a ON a.Id = m.AccountId
WHERE m.Id = @id AND f.ReadLevel <= @Account.AccessLevel
").SingleOrNone().Match(
_ => View(new MessageModel {
ID = id,
Info = _,
Text = FormatMessageBody(id, _.Origin)
}),
() => ErrorMessageBox("Сообщение не найдено"));
//Тип IMessageInfo генерируется автоматически по полям запроса, поэтому
//его код смотреть не надо
G>А что же ты на ассемблере не пишешь? Ты же знаешь что компьютер должен делать, зачем извращаться через посредника?
Я не знаю какие ассемблерные команды должны быть.
SQL это высокоуровневый язык, специально разработанный под реляционную модель.
G>Если ты знаешь как sql должен выглядеть, то ты или ясновидящий, или запросы примитивные. Но скорее всего ты только думаешь что знаешь.
Скорее всего, ты только думаешь, что я не знаю.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Перепиши с ним. AP>Печатал без компиляции и без CheckAllQueries, возможны опечатки.
Напомню что linq показывает опечатки и несоответствия типов в процессе набора.
AP>
AP> return Query<IMessageInfo>.New(new {id}, @"
AP>SELECT f.ShortName ForumShortName, m.CreatedOn, m.Subject, a.Origin
AP>FROM Message m
AP> JOIN Forum f ON f.Id = m.ForumId
AP> OUTER JOIN Account a ON a.Id = m.AccountId
AP>WHERE m.Id = @id AND f.ReadLevel <= @Account.AccessLevel
AP>").SingleOrNone().Match(
AP> _ => View(new MessageModel {
AP> ID = id,
AP> Info = _,
AP> Text = FormatMessageBody(id, _.Origin)
AP> }),
AP> () => ErrorMessageBox("Сообщение не найдено"));
AP> //Тип IMessageInfo генерируется автоматически по полям запроса, поэтому
AP> //его код смотреть не надо
AP>
G>>А что же ты на ассемблере не пишешь? Ты же знаешь что компьютер должен делать, зачем извращаться через посредника? AP>SQL это высокоуровневый язык, специально разработанный под реляционную модель.
SQL в посредниках не нуждается.
Здравствуйте, gandjustas, Вы писали:
G>При N=5 человек уже не может это делать.
Такой ты наивный... А как же раньше подобные задачи решались? )))
Точно так же генерили SQL аж бегом.
G>Мой пример собирается в студии, я только оттуда несущественные детали убрал. Ты же пропустил довольно важные части.
А толку? Если в базе появилось лишнее поле, а ты забыл добавить его в свои объекты, то тебе компилятор не поможет. Зато помогли бы тулзы построения запросов — ты бы видел, что у тебя в базе.
Более того, при ручной разработке запросов есть тенденция, что эти запросы будут оседать на стороне базы. А в твоём случае все запросы — динамические, даже когда 90% их статические или требует тривиальных аргументов. А у тебя выходит самый тормозной вариант из всех.
Здравствуйте, gandjustas, Вы писали:
НС>>Генерировать мапперы по IL можно и в компайл-тайме. То что EF этого не умеет вовсе не означает, что это вообще невозможно. G>Только сейчас это нельзя включить в библиотеку.
Можно и включить, ilmerge никто пока не отменял. Но ты не находишь, что от фатального недостатка ты перешел к мелким неудобствам?
НС>>Это никак не избавляет от того, о чем говорит IB. G>Он говорит о тормознутом мепинге
Нет, он говорит о неправильной архитектуре, требующей лишних шагов.
G>, при компиляции модели в код и генерации mapping view во время компиляции можно устранить тормоза полностью.
Только тормоза во время компиляции. Но и этого у EF все равно нет.
НС>>При чем тут SOAP? G>При то что это основа ws-* вебсервисов, на которые wcf рассчитан в первую очередь.
То что он рассчитан в первую очередь, это уже твои фантазии. Я лично знаком с некоторыми из архитекторов WCF, и многопротокольность там закладывалась с самого начала как базовое требование. Причем не только в плане message протоколов, но и протоколов сетевых. И в том числе поэтому WCF на порядок гибче и шире по функционалу WebAPI, но и, как следствие, имеет более крутую learning curve.
G>>>Я написал что они взаимоисключающие? Самая проблема что они все разные. НС>>Не вижу проблемы. G>Ну попробуй сходу написать код для хоста wcf с di в классы сервисов.
Да писал не раз. Если понимаешь как WCF устроен — особых проблем нет. Ну и DI сам по себе — далеко не серебряная пуля.
G> Что для этого нужно?
Тривиально реализовать крошечный интерфейс — IInstanceProvider. Один раз, если уж тебе так DI мил.
G> Толи factory сделать, толи service behavior поменять и это настолько разные апи, что хрен разберешься как правильно.
Ну так и проблема в том что ты не разобрался, а не в WCF.
НС>>Это одна строчка. G>Это больше, особенно когда у тебя хост не в asp.net
Нет. Ты опять не разобрался.
НС>>Есть. G>По сравнению с webapi считай что нет.
По сравнению с WebAPI она на порядок круче, потому что позволяет создавать собственные шаблоны конфигураций. Но ты, я понимаю, опять не разобрался.
НС>>Ты лучше сам сходи и прочитай официальное введение в архитектуру WCF, а не пиши здесь ерунду. G>Зачем мне официальное чтото читать?
Ну конечно, ссылки на собственный блог, особенно учитывая что ты тут про WCF пишешь, куда убедительнее.
НС>Ну, собственно, мне добавить нечего кроме того, что IMessageInfo ты забыл привести.
У меня нет схемы твоей базы, не на чем прогонять CheckAllQueries.
Укажи, пожалуйста, опечатки (сэкономь моё время). По поводу IMessageInfo я написал: “Тип IMessageInfo генерируется автоматически по полям запроса, поэтому его код смотреть не надо”.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Ну, собственно, мне добавить нечего кроме того, что IMessageInfo ты забыл привести. AP>У меня нет схемы твоей базы, не на чем прогонять CheckAllQueries.
Схема моей базы тут не причем. Потому что id находится в одной таблице, а Origin в другой, о чем ты и сам догадался. Это означает что твой тип IMessageInfo adhoc, и нужен исключительно для этого конкретного запроса. Поэтому его нужно было привести.
AP>“Тип IMessageInfo генерируется автоматически по полям запроса, поэтому его код смотреть не надо”.
Т.е. пишем запрос, компилируем, потом его дописываем, так что ли?
НС>Потому что сам посредник. И работы над устранением sql из цепочки LINQ-SQL Server уже ведутся.
Совсем уберут SQL? SQL Server без SQL. Как ты там написал, заодно уберут лишнее количество пользователей.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Потому что сам посредник. И работы над устранением sql из цепочки LINQ-SQL Server уже ведутся. AP>Совсем уберут SQL?
НС>Т.е. пишем запрос, компилируем, потом его дописываем, так что ли?
Пишем код с запросом, IMessageInfo оставляем пустым. Запускаем CheckAllQueries, он выдает сообщение о том, что поля типа и запроса не совпадают, и в сообщении указывается полный код для IMessageInfo, который должен быть (генерируется на основе GetSchemaTable). Копирование текста IMessageInfo в cs-исходник сейчас делаем вручную. Хорошо бы это автоматизировать, но это не очень критично. Читаемость не страдает, поскольку IMessageInfo можно положить в укромное место и не заглядывать туда. А написание кода не такая большая проблема. Есть желание и имена таких типов сделать генеренными T001...T999, т.е. такие вот анонимные типы, но без ограничение на использование только внутри метода.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Т.е. пишем запрос, компилируем, потом его дописываем, так что ли? AP>Пишем код с запросом, IMessageInfo оставляем пустым.
Но руками объявление таки придется написать, хоть и пустое.
AP> Запускаем CheckAllQueries, он выдает сообщение о том, что поля типа и запроса не совпадают, и в сообщении указывается полный код для IMessageInfo
AP>Копирование текста IMessageInfo в cs-исходник сейчас делаем вручную.
Прелестно.
AP> Хорошо бы это автоматизировать, но это не очень критично. Читаемость не страдает, поскольку IMessageInfo можно положить в укромное место и не заглядывать туда.
Вобщем, ты все отлично продемонстрировал. Я бы только не заикался после этого насчет сложности использования ExpressionMethod в linq2db.
НС>Будут работать в режиме совместимости, пока поддержку нового протокола не добавят.
А декомпозицию экспрешеннов в продукт от Microsoft когда добавят? Подозреваю, если этим вопросом озаботится Hejlsberg, то что-нибудь более удобоваримое получится, чем *Expr методы.
Как ты там написал, заодно уберут лишнее количество пользователей. 
