AP>>А то, что linq не разрабатывался для динамических запросов НС>Заладил как истукан. Это все ни о чем. Есть конкретные задачи и есть их решения.
Ха, задача ... А как там насчет Вьетнама компьютерной науки?
AP>>Если метод "ordinals.Materialize(reader)" еще не является ORM-ом, НС>Вообще то уже является.
Тогда и в таком коде уже есть ORM "new Post(reader.GetInt32(idOrdinal), reader.GetDateTime(creationDateOrdinal))". Relation есть, Object есть, Mapping тоже есть. Т.е. без ORM, действительно, очень сложно написать.
AP>> то на твой вопрос можно ответить и переписать твой код без ORM. НС>Перепиши.
Если Materialize это уже ORM, то у меня нет варианта без ORM.
Всё это так, да. Но вот Фаулер пишет о том, что relation-ы в памяти не всегда прокатывают, ему нужны какие-то Объекты.
Avoiding the problem
...
To use a relational model in memory basically means programming in terms of relations, right the way through your application. In many ways this is what the 90's CRUD tools gave you. They work very well for applications where you're just pushing data to the screen and back, or for applications where your logic is well expressed in terms of SQL queries. Some problems are well suited for this approach, so if you can do this, you should. But its flaw is that often you can't. http://martinfowler.com/bliki/OrmHate.html
Т.е. Фаулер пишет, что если релейшенов в памяти достаточно, то это позволяет избежать ORM проблем. Materialize всего лишь вытаскивает релешен в память.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Что же они так? Спросили бы меня как надо было делать EF с самого начала. Я бы им ещё лет 5 назад рассказал. Стоило выпускать 6 релизов, чтобы понять, что 7-й нужно переписывать с нуля.
G>>В .NET дофига компонент, которые лет 5 назад стоило переписать с нуля, но менеджмент видимо не позволял.
IT>EF — это всё же отдельно от всего лежащий кусок кала.
Года два назад отдали в ASP.NET
IT>Ваня правильнос сказал, что практикующим девелоперам ещё лет 10 назад стало понятно каким должно быть средство работы с БД. Но команда EF шла на пролом своим путём.
Если всем понятно, то почему никто не сделал?
G>>С появлением Roslyn и K Runtime перепишут под шумок кучу всего.
IT>Новый компилятор позволяет переписать устаревший код и сделать его лучше. Но новый компилятор не поможет сделать лучше новую архитектуру.
Да ладно? Например с помощью compiler as service можно сделать compile time генерация маппинга DataReader на объекты как минимум или запросто компилировать в реальный IL edmx-модель, убрав весь оверхед, или делать compile-time проверяемые текстовые запросы с декомпозицией (как мечтает Поляков).
IT>После прочтения их пресс-релиза у меня уже возникают какие-то смутные сомнения. Особенно по поводу "EF7 is Lightweight and Extensible".
Ты тоже оцениваешь технологии по пресс-релизам? Лучше посмотри исходники на гитхабе.
IT>Один из самых "Extensible" продуктов MS — WCF, хрень, с которой без гугля работать невозможно в принципе. Куда заведут ребят из команды EF новые возможности Рослина не знает никто.
Вот сделали WebAPI, фактически замена WCF, можно написать SOAP форматтер и роутинг через SOAP пакет и получится почти тоже самое.
WebAPI вроде как всем нравится, никто не жалуется.
Самые важные отличия WebAPI от WCF
1) У WCF очень многослойный API, у WebAPI довольно мало вызовов между котроллером и HttpHandler\HttpListener
2) У обоих куча Extensibility Points, но в WebAPI почти все делается через встроенный IoC, а WCF для каждого расширения применяется свой метод (конфиги, атрибуты, классы итп)
3) У WCF очень много конфигурации, даже для запуска простого сервиса нужно создать кучу объектов с кучей параметров или прописать дофига всего в конфигах, в WebAPI большая часть построена на "соглашениях". Причем соглашения можно настроить, но по умолчанию они покрывают самые распространенные случаи.
По сути в WebAPI используется сервисно-ориентированная архитектура, тогда как WCF — образец классического ООП.
Возвращаясь к теме EF — начиная с версии 5 активно внедряется такой же сервисный подход. Тоже есть встроенный IoC, тоже куча подменяемых сервисов и соглашения (положительное влияние asp.net). Но под капотом там еще остался старый EF, построенный на принципах ООП, который и хотят в версии 7 выкорчевать из EF.
Если бы строк было достаточно для использования SQL в программе, то linq никогда бы не придумали. Если ты веришь что все можно сделать используя только строки, то мне тебя искренне жаль.
Здравствуйте, gandjustas, Вы писали:
G>Да ладно? Например с помощью compiler as service можно сделать compile time генерация маппинга DataReader на объекты как минимум
Для этого компилятор не нужен, вполне достаточно генерировать маппинг по IL. Это, заоодно, еще и универсально по отношению к конкретному языку будет.
Ковырятся с интеграцией в компилятор нужно строго в том случае, где нам необходимо вмешательство в алгоритмы работы компилятора по основному коду. Например введение новых типов. Для маппера это все без особой надобности.
G> или запросто компилировать в реальный IL edmx-модель, убрав весь оверхед
Это можно, но пользы от этого немного.
IT>>Один из самых "Extensible" продуктов MS — WCF, хрень, с которой без гугля работать невозможно в принципе. Куда заведут ребят из команды EF новые возможности Рослина не знает никто. G>Вот сделали WebAPI, фактически замена WCF
Конечно же нет. WebAPI решает существенно более узкие задачи, не особо с WCF пересекающиеся. Если у него RESTful сервисы — основная задача, то для WCF это побочная фича.
G>а WCF для каждого расширения применяется свой метод (конфиги, атрибуты, классы итп)
Это тоже неверно. Все эти методы параллельные, а не взаимоисключающие.
G>3) У WCF очень много конфигурации, даже для запуска простого сервиса нужно создать кучу объектов с кучей параметров или прописать дофига всего в конфигах
И это неверно. Для типовых юзкейсов есть готовые наборы конфигураций. Самому их собирать нужно только если типовые не позволяют сконфигурироваться в то что нужно.
G>По сути в WebAPI используется сервисно-ориентированная архитектура, тогда как WCF — образец классического ООП.
А это просто вранье. SOA, собственно, оформилась как архитектура именно при создании WCF и была положена в его основу.
G>Если бы строк было достаточно для использования SQL в программе, то linq никогда бы не придумали. Если ты веришь что все можно сделать используя только строки, то мне тебя искренне жаль.
Мне искренне жаль тех, кто слепо верит в то, что, закрывая SQL linq-ом получается якобы улучшение: быстрота разработки, maintenance, развитие и т.д. На самом деле, linq решает одни проблемы и создает другие. Совокупно становится не лучше, а чаще maintenance и развитие становится только хуже. Очередной виток Вьетнама компьютерной науки.
Точнее таких девелоперов мне не жаль, поскольку сами виноваты, занимаются самообманом. Жаль их заказчиков, они то не о чем не подозревают, что нанятые девелоперы не занимаются их бизнес логикой, а тратят время на экспрешены.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Тогда и в таком коде уже есть ORM "new Post(reader.GetInt32(idOrdinal), reader.GetDateTime(creationDateOrdinal))".
Нет.
AP>>> то на твой вопрос можно ответить и переписать твой код без ORM. НС>>Перепиши. AP>Если Materialize это уже ORM, то у меня нет варианта без ORM.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Мне искренне жаль тех, кто слепо верит в то, что, закрывая SQL linq-ом получается якобы улучшение: быстрота разработки, maintenance, развитие и т.д.
Это не вопрос веры, это результат конкретного опыта. У меня, к примеру, был проект, написанный на BLT со склейкой строк. Потом его переписали на LINQ. Объем кода и сложность его модификации уменьшились в разы. А вот у тебя именно что вера, что твой велосипед круче линка. Ну и правда, зря что ли ты его делал?
НС>Это не вопрос веры, это результат конкретного опыта. У меня, к примеру, был проект, написанный на BLT со склейкой строк. Потом его переписали на LINQ. Объем кода и сложность его модификации уменьшились в разы. А вот у тебя именно что вера, что твой велосипед круче линка. Ну и правда, зря что ли ты его делал?
Ну, ну, зря делал... Я что мазохист что ли от хорошей жизни бесплатно делать библиотеку. Нахрена мне это надо? ... С большим удовольствием взял бы EF и занимался бы на работе реализацией бизнес логики, за которую мне платят. ... А опыт показывает, что при использовании LINQ всегда чувствуется профессиональная неловкость: блин, да, дайте мне уже самому написать SQL, который я знаю как должен выглядеть, а не заставляете меня извращаться через посредника в виде linq. Короче с удовольствием выкинул бы свой проект, если бы было чем заменить.
НС>Опять какие то твои персональные психологические выверты. Ни о чем.
Ты сам свернул на дорожку обсуждения моей личности: "Ну и правда, зря что ли ты его делал?".
НС>Это не вопрос веры, это результат конкретного опыта. У меня, к примеру, был проект, написанный на BLT со склейкой строк. Потом его переписали на LINQ. Объем кода и сложность его модификации уменьшились в разы. А вот у тебя именно что вера, что твой велосипед круче линка. Ну и правда, зря что ли ты его делал?
Т.е. вопрос лишь в том, что тебе нужно приобрести опыт работы с автоматической проверкой строковых запросов? Только после этого ты сможешь давать оценку. Может оказаться аналогично "сложность его написания и модификации уменьшится в разы" относительно linq.
Здравствуйте, Alexander Polyakov, Вы писали:
G>>1) чем это компилировать? AP>Приведенный код компилируется обычным C# компилятором. Для проверки запросов надо дернуть метод CheckAllQueries AP>
этот подход не взлетит, если нет доступа к имплементации оригинального запроса.
а такое встречается сплош и рядом — севременные приложения без DI/IOC уже давно не пишут.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Да ладно? Например с помощью compiler as service можно сделать compile time генерация маппинга DataReader на объекты как минимум
НС>Для этого компилятор не нужен, вполне достаточно генерировать маппинг по IL. Это, заоодно, еще и универсально по отношению к конкретному языку будет. НС>Ковырятся с интеграцией в компилятор нужно строго в том случае, где нам необходимо вмешательство в алгоритмы работы компилятора по основному коду. Например введение новых типов. Для маппера это все без особой надобности.
Повторяю — compile-time генерация мапперов, чтобы убрать весь оверхед в рантайме, и чтобы работать могло в средах где генерация невозможна, типа winrt.
G>> или запросто компилировать в реальный IL edmx-модель, убрав весь оверхед
НС>Это можно, но пользы от этого немного.
Как минимум IB не будет потом рассказывать про тормознутую модель. Тоже польза
А по факту в ef долгое время была проблема генерации mapping view. Начиная с ef5 оно генерируется один раз и кешируется, но это происходит в рантайме и добавляет тормозов при первом запуске.
IT>>>Один из самых "Extensible" продуктов MS — WCF, хрень, с которой без гугля работать невозможно в принципе. Куда заведут ребят из команды EF новые возможности Рослина не знает никто. G>>Вот сделали WebAPI, фактически замена WCF
НС>Конечно же нет. WebAPI решает существенно более узкие задачи, не особо с WCF пересекающиеся. Если у него RESTful сервисы — основная задача, то для WCF это побочная фича.
Это идеология. на практике прикрутить к webapi soap-форматтер, sop-ротуы и генератор wsdl, то будет решать те же задачи.
G>>а WCF для каждого расширения применяется свой метод (конфиги, атрибуты, классы итп)
НС>Это тоже неверно. Все эти методы параллельные, а не взаимоисключающие.
Я написал что они взаимоисключающие? Самая проблема что они все разные.
G>>3) У WCF очень много конфигурации, даже для запуска простого сервиса нужно создать кучу объектов с кучей параметров или прописать дофига всего в конфигах
НС>И это неверно. Для типовых юзкейсов есть готовые наборы конфигураций. Самому их собирать нужно только если типовые не позволяют сконфигурироваться в то что нужно.
Эти типовые конфигурации тоже надо прописывать в кофиге или в коде. Нету нормальной системы умолчаний.
G>>По сути в WebAPI используется сервисно-ориентированная архитектура, тогда как WCF — образец классического ООП.
НС>А это просто вранье. SOA, собственно, оформилась как архитектура именно при создании WCF и была положена в его основу.
Ты по ссылке внимательно прочитай для начала.
Здравствуйте, gandjustas, Вы писали:
G>Повторяю — compile-time генерация мапперов, чтобы убрать весь оверхед в рантайме
Генерировать мапперы по IL можно и в компайл-тайме. То что EF этого не умеет вовсе не означает, что это вообще невозможно.
НС>>Это можно, но пользы от этого немного. G>Как минимум IB не будет потом рассказывать про тормознутую модель.
Это никак не избавляет от того, о чем говорит IB.
НС>>Конечно же нет. WebAPI решает существенно более узкие задачи, не особо с WCF пересекающиеся. Если у него RESTful сервисы — основная задача, то для WCF это побочная фича. G>Это идеология. на практике прикрутить к webapi soap-форматтер, sop-ротуы и генератор wsdl, то будет решать те же задачи.
При чем тут SOAP?
НС>>Это тоже неверно. Все эти методы параллельные, а не взаимоисключающие. G>Я написал что они взаимоисключающие? Самая проблема что они все разные.
Не вижу проблемы.
НС>>И это неверно. Для типовых юзкейсов есть готовые наборы конфигураций. Самому их собирать нужно только если типовые не позволяют сконфигурироваться в то что нужно. G>Эти типовые конфигурации тоже надо прописывать в кофиге или в коде.
Это одна строчка.
G> Нету нормальной системы умолчаний.
Есть.
НС>>А это просто вранье. SOA, собственно, оформилась как архитектура именно при создании WCF и была положена в его основу. G>Ты по ссылке внимательно прочитай для начала.
Ты лучше сам сходи и прочитай официальное введение в архитектуру WCF, а не пиши здесь ерунду.
Здравствуйте, Alexander Polyakov, Вы писали:
G>>Если бы строк было достаточно для использования SQL в программе, то linq никогда бы не придумали. Если ты веришь что все можно сделать используя только строки, то мне тебя искренне жаль. AP>Мне искренне жаль тех, кто слепо верит в то, что, закрывая SQL linq-ом получается якобы улучшение: быстрота разработки, maintenance, развитие и т.д. На самом деле, linq решает одни проблемы и создает другие. Совокупно становится не лучше, а чаще maintenance и развитие становится только хуже.
Если бы это было правдой то не изобрели бы linq и query object вообще.
Очередной виток Вьетнама компьютерной науки.
AP>Точнее таких девелоперов мне не жаль, поскольку сами виноваты, занимаются самообманом. Жаль их заказчиков, они то не о чем не подозревают, что нанятые девелоперы не занимаются их бизнес логикой, а тратят время на экспрешены.
Как раз те кто пишут linq — экономят. Особенно на поддержке. А такие как ты тратят, прикрываясь тем что занимаются «бинес-логикой».
Ты ведь сколько не написал в этой теме, но по факту не привел ни одного довода почему linq использовать неэффективно. Все что ты привел доказывает обратное, особенно примеры с «проверяемыми запросами».
G>Ты ведь сколько не написал в этой теме, но по факту не привел ни одного довода почему linq использовать неэффективно. Все что ты привел доказывает обратное, особенно примеры с «проверяемыми запросами».
Я привел достаточно доводов. linq не способен просто сделать базовую операцию декомпозиции: выделение фрагмента кода. Вы показали либо заворачивание краткого синтаксиса linq в хелперные методы (и получение громоздкого синтаксиса аля Query Object)?, либо самопальные костыли из linq2db.
G>Все что ты привел доказывает обратное, особенно примеры с «проверяемыми запросами».
Каким образом ты видишь обратное? Пока голословное утверждение.
T>этот подход не взлетит, если нет доступа к имплементации оригинального запроса. T>а такое встречается сплош и рядом — севременные приложения без DI/IOC уже давно не пишут.
IOC совершенно параллелен CheckAllQueries. Выложу на github всё станет ясно по коду.
Здравствуйте, Alexander Polyakov, Вы писали:
G>>Ты ведь сколько не написал в этой теме, но по факту не привел ни одного довода почему linq использовать неэффективно. Все что ты привел доказывает обратное, особенно примеры с «проверяемыми запросами». AP>Я привел достаточно доводов. linq не способен просто сделать базовую операцию декомпозиции: выделение фрагмента кода.
Я тебе привел ссылку как это делается. Копируй себе и выделяй сколько влезет.
AP>Вы показали либо заворачивание краткого синтаксиса linq в хелперные методы (и получение громоздкого синтаксиса аля Query Object)?, либо самопальные костыли из linq2db.
Любые костыли лучше склейки строк, ибо компилятором проверяются. А ты попробуй текстовые запросы разобрать на кусочки так, чтобы предикаты были в одной сборке, проекции в другой, а собирался запрос в третьей и все три части проверялись компилятором.
G>>Все что ты привел доказывает обратное, особенно примеры с «проверяемыми запросами». AP>Каким образом ты видишь обратное? Пока голословное утверждение.
Я тебе писал про добавление проекций. Ты забыл уже?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Повторяю — compile-time генерация мапперов, чтобы убрать весь оверхед в рантайме
НС>Генерировать мапперы по IL можно и в компайл-тайме. То что EF этого не умеет вовсе не означает, что это вообще невозможно.
Только сейчас это нельзя включить в библиотеку.
НС>>>Это можно, но пользы от этого немного. G>>Как минимум IB не будет потом рассказывать про тормознутую модель.
НС>Это никак не избавляет от того, о чем говорит IB.
Он говорит о тормознутом мепинге, при компиляции модели в код и генерации mapping view во время компиляции можно устранить тормоза полностью.
НС>>>Конечно же нет. WebAPI решает существенно более узкие задачи, не особо с WCF пересекающиеся. Если у него RESTful сервисы — основная задача, то для WCF это побочная фича. G>>Это идеология. на практике прикрутить к webapi soap-форматтер, sop-ротуы и генератор wsdl, то будет решать те же задачи.
НС>При чем тут SOAP?
При то что это основа ws-* вебсервисов, на которые wcf рассчитан в первую очередь.
НС>>>Это тоже неверно. Все эти методы параллельные, а не взаимоисключающие. G>>Я написал что они взаимоисключающие? Самая проблема что они все разные.
НС>Не вижу проблемы.
Ну попробуй сходу написать код для хоста wcf с di в классы сервисов. Что для этого нужно? Толи factory сделать, толи service behavior поменять и это настолько разные апи, что хрен разберешься как правильно.
НС>>>И это неверно. Для типовых юзкейсов есть готовые наборы конфигураций. Самому их собирать нужно только если типовые не позволяют сконфигурироваться в то что нужно. G>>Эти типовые конфигурации тоже надо прописывать в кофиге или в коде.
НС>Это одна строчка.
Это больше, особенно когда у тебя хост не в asp.net
G>> Нету нормальной системы умолчаний.
НС>Есть.
По сравнению с webapi считай что нет. А уж поменять умолчания, которые зашиты в 100500 разных классов это вообще жесть.
НС>>>А это просто вранье. SOA, собственно, оформилась как архитектура именно при создании WCF и была положена в его основу. G>>Ты по ссылке внимательно прочитай для начала.
НС>Ты лучше сам сходи и прочитай официальное введение в архитектуру WCF, а не пиши здесь ерунду.
Зачем мне официальное чтото читать? Я в ilspy код читаю, он говорит гораздо больше.
