Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Gattaka, Вы писали:
G>>Здравствуйте, gandjustas, Вы писали:
G>>>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить G>>>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял. G>>Выгоднее это да, но насколько? План запроса компилируется пару милисекунд, можно для каждого конкретного посмотреть в плане. И на чем мы экономим? Если сам запрос выполняется пару секунд. Ну... если хорошо скомпилировался. Если плохо — полчаса. Здесь баланс нужно соблюдать. На самом деле что ORM хорошо делает, это простейший CRUD, самый простейший. И сценарий что вы описали. Но это по факту Read. G>Баланс чего? Тут нет tradeoff, запросы, сгенерированные Linq не требуют перекомпиляции, а рукопашные требуют.
G>>Ну и что это за уровень абстракции в таком случае? Это всего лишь способ писать SQL на C#. Извращение... G>Ну и пусть извращение, какая разница? Я готов заниматься любыми извращениями если сокращает затраты.
Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
Я уже описывал что за проблемы — при работе с дискриминаторами в 2 раза больше джойнов вместо условий в самих джойнах. И что тогда будет толку от кучи конкретных запросов, которые не перекомпилируются, но содержат лишние джойны?
Если посмотреть на EF там постоянно запросы вида select ... from (select ... запрос...) — почему-то селект из селекта, очень странно.
Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.
G>Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
Типичное веб-приложение а 98% состоит из выборок, а их удобнее делать в генераторе запросов типа linq, а не в ХП.
G>Я уже описывал что за проблемы — при работе с дискриминаторами в 2 раза больше джойнов вместо условий в самих джойнах. И что тогда будет толку от кучи конкретных запросов, которые не перекомпилируются, но содержат лишние джойны?
Это проблема конкретно NHibernate и модели, а не ORM в принципе. Выбирай нормальные средства.
G>Если посмотреть на EF там постоянно запросы вида select ... from (select ... запрос...) — почему-то селект из селекта, очень странно.
derived table прекрасно оптимизируются, смотри планы запросов.
G>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.
хз. а на что вообще это влияет?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Gattaka, Вы писали:
G>>Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы. G>Типичное веб-приложение а 98% состоит из выборок, а их удобнее делать в генераторе запросов типа linq, а не в ХП.
Ну тифичное веб-приложение это да.
G>>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности. G>хз. а на что вообще это влияет?
Ну вобщето при обновлении лучше обновлять только то, что вы изменили. Как и с выборкой. Как стреляет. Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так...
Здравствуйте, Gattaka, Вы писали:
G>>>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности. G>>хз. а на что вообще это влияет? G>Ну вобщето при обновлении лучше обновлять только то, что вы изменили.
Кому лучше? Ты хоть представляешь как работает обновление на уровне страниц?
G>Как и с выборкой.
Не как с выборкой
G>Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так...
Уверен, что отсутствие поля в update не вызывает пересчет вьюшки? Я что-то очень сомневаюсь.
Здравствуйте, gandjustas, Вы писали:
G>>Ну вобщето при обновлении лучше обновлять только то, что вы изменили. G>Кому лучше? Ты хоть представляешь как работает обновление на уровне страниц?
Ну хотябы потому что трафик за счет самого запроса больше. Там ведь у сущности могут быть и с мегатекстом и бинарной гадостью всякой. Да даже если просто поля... В любом случае лучше меньше трафика. Насчет апдейта на самом сервере я соглашусь что в большенстве случаев это почти то же самое. Но если у вас фрагментация страниц большая или есть расщипленные страницы? Вобщем ИМХО очевидно, что лучше минимизировать объем обнавления данных — это хороший стиль. Как зубы чистить. С какого бабуя я должен то же самое на то же самое перетирать? Только из-за того что у разработчиков ОРМ — лениво писать грамотный код.
G>>Как и с выборкой. G>Не как с выборкой
G>>Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так... G>Уверен, что отсутствие поля в update не вызывает пересчет вьюшки? Я что-то очень сомневаюсь.
Проверяли. А что оно будет обновлятс? Поле, которое фигурирует в вьюшке не меняется. А в случае с перезаписью то же самое на то же самое — формально меняется...
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>Только из-за того что у разработчиков ОРМ — лениво писать грамотный код.
Это у разработчиков NHibernate, в EF проверил — в Update уходят только обновленные поля. В linq2db уверен то же самое.
Здравствуйте, Baudolino, Вы писали:
IT>>Не совсем так. DAL изолирует работу с базой в терминах самой базы от остальной части приложения путём конвертации терминов приложения в термины БД и наоборот. B>Ну в общем, да. Можно еще короче сказать: абстрагируют работу с хранилищем, причем не обязательно БД:
Нет. Основная функция DAL — изоляция работы с БД от остальной части приложения. То, что это обладает ещё какими-то другими свойствами — это побочный эффект. Например, ту же обстракцию БД вполне хорошо, даже лучше чем DAL выполняет LINQ, но принципиально по-другому.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить G>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.
Здравствуйте, gandjustas, Вы писали:
G>Это у разработчиков NHibernate, в EF проверил — в Update уходят только обновленные поля. В linq2db уверен то же самое.
В linq2db вообще нет такого. Вместо этого linq2db поддерживат DML и DDL.
Если нам не помогут, то мы тоже никого не пощадим.
_>>А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек. V>Фаулер отличает репозиторий и шлюз таблицы — у него это разные концепции. Проблема примеров — им надо показать всё и сразу, поэтому они очень сильно упрощают код. Код из примеров нельзя воспринимать как руководство к действию.
Какой смысл лепить отдельный паттерн "шлюз таблицы" Идиотизм. Это тоже самое, что и репозиторий, только конкретно типизированный под бд. Т.е. это одна и та же концепция.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gattaka, Вы писали:
G>>А не могли бы вы приблизительную сигнатуру вашего класса показать? Так чтобы точно понимать...
IT>Не мог бы. Там и сигнатуры особенной нет. Это просто класс без всяких интерфейсов и паттернов, в котором куча коллекций с данными. Методы для инициализации и ещё какой-то фигни по мелочи. Просто большой контейнер. Это его основная задача.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Vladek, Вы писали:
_>>>А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек. V>>Фаулер отличает репозиторий и шлюз таблицы — у него это разные концепции. Проблема примеров — им надо показать всё и сразу, поэтому они очень сильно упрощают код. Код из примеров нельзя воспринимать как руководство к действию.
S>Какой смысл лепить отдельный паттерн "шлюз таблицы" Идиотизм. Это тоже самое, что и репозиторий, только конкретно типизированный под бд. Т.е. это одна и та же концепция.
У них разные задачи. Репозиторий может совершенно не знать как именно хранятся данные. Попробуйте глянуть на это с такой точки зрения: вам надо протестировать отдельно бизнес логику и отдельно правильное создание бизнес объектов юнит тестами. Как вы бедете изолироваться от хранилища, если все свалите в один класс?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Gattaka, Вы писали:
G>>Здравствуйте, IT, Вы писали:
IT>>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс. G>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM. G>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.
Эпическое движение стиля кодирования.
Помню, сначала писали SQL-стейтменты в коде.
Потом информации о том, как это плохо поддерживать появилось больше и начали перемещать стейтменты в хранимки.
Потом появился linq. SQL-стейтменты снова оказались в коде.
Теперь снова появляется много информации о том, как это хреново поддерживать...
Здравствуйте, another_coder, Вы писали:
_>Эпическое движение стиля кодирования. _>Помню, сначала писали SQL-стейтменты в коде. _>Потом информации о том, как это плохо поддерживать появилось больше и начали перемещать стейтменты в хранимки. _>Потом появился linq. SQL-стейтменты снова оказались в коде. _>Теперь снова появляется много информации о том, как это хреново поддерживать...
_>Не пора ли уже остановиться?
Не так все было.
С момента появления серверных СУБД было выгодно делать хранимки, они реально быстрее работали, чем adhoc запросы.
Ситуация кардинально поменялась в начале 2000-х, примерно в это время во всех популярных СУБД быстродействие adhoc запросов и хранимок сравнялась.
Тогда же появился холивар ХП vs запросы в коде. Оба подхода имели преимущества и недостатки.
Когда появился linq холивар можно было заканчивать. Ни одного реального преимущества у хранимок не осталось, кроме сценариев тупо не покрытых linq. Но холивар по привычке продолжился.
Относительно недавно появился linq2db, который покрывает любые сценарии работы с данными из приложения с помощью linq.
S>>Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания sql запросов (специалиста), он больше одного запроса написать не сможет? Не считая того, что вообще говоря это должно быть компетенцией разработчика, отв. за соотв. таблицы (сущности). G>Конечно сможет. И два сможет, и десять и может даже 50. Для статистики — у меня в очень простом приложении с 5 таблицами в базе получилось суммарно 60 разных запросов. А нанимать спеца отдельно по БД для базы менее чем два десятка таблиц никто не будет. Вот и посчитай какое количество запросов ему надо будет поддерживать.
Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.
Здравствуйте, Sharov, Вы писали:
S>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.
И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Sharov, Вы писали:
S>>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.
G>И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Sharov, Вы писали:
S>>>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает. G>>И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if? S>Если самописные быстрее, почему бы и нет?
А с чего они могут быть быстрее? И насколько они быстрее, что стоят десятикратного (а на деле больше) геморроя?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, another_coder, Вы писали:
_>>Здравствуйте, gandjustas.
_>>На мой взгляд, вы не разделяете сущности от их технической реализации. В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service). Весь функционал, который относится к доступу к данным спрятан там же и наружу не показывается. И вот тут как раз приходин на помощь объект, представляющий собой DAO. Конкретная его реализация может быть разной и зависить от уровня закладываемой абстракции в архитектуру. Это может быть EF, а может быть и просто объект с простым CRUD интерфейсом.
G>Ок, давайте конкретнее. Пусть у вас есть "хранилище данных" сотрудников. G>Фактически это будет три разных хранилища: G>1) Список в памяти — List<T> G>2) База данных G>3) Веб-сервис, который имеет только методы получения и сохранения по ID.
G>У вас задача поднять сотрудникам определенной категории зарплату на 10%.
G>Какой интерфейс универсального "хранилища данных" вы спроектируете для решения этой задачи. G>Естественно писать заведомо неэффективный код — моветон.
var employees = await employeeRepo.GetEmployeesAsync(EmployeeCategory.SpecificCategory);
foreach (var employee in employees)
{
employee.ChangeSalary(factor: +0.1f);
}
await Employee.SaveChangesAsync(employees);
Тут репозиторий знает откуда брать сотрудников (и их менеджеров, то есть репозиторий возвращает агрегаты из DDD), сотрудники знают как менять себе (в ООП лампочка вкручивает себя в люстру сама) зарплаты (все проверки и согласования с менеджерами внутри) и сохранять изменения. Хранилище тут находится уровнем ниже и используется репозиторием и сотрудниками — это может быть простой шлюз таблицы, обменивающийся с репозиторием и сотрудниками простыми объектами (DTO). И уже само хранилище владеет знанием откуда данные собственно берутся.
Зависимости:
Объекты предметной области -> объекты передачи данных -> объекты реализации (объекты EF, объекты веб-сервисов, а List<T> хранит объекты передачи данных)
Если нам не помогут, то мы тоже никого не пощадим.
Идиотизм. Это тоже самое, что и репозиторий, только конкретно типизированный под бд. Т.е. это одна и та же концепция.
