Здравствуйте, Tom, Вы писали:
ili>>так вот я не понимаю, зачем нужны обертки, почему нельзя пользоваться классами модели предметной области?... Tom>И я не понимаю где мне их брать, когда для данной вью их просто нет. Например когда стора возвращает агрегатЫ
отчет? а почему дата-тейбл не подходит? (мне и вправду интересно)
Tom>Или обьекты предметной области универсальный ответ на "Ответ на главный вопрос жизни, вселенной и всего такого" (c) Дуглас Адамс ?
42
VD>>Сдается мне триггеры на полноценном языке могли бы пригодиться многим. IB>А мне сдается что нет. Ни триггеры, ни хранимки. Всю серьезную логику не связанную непосредственно с SQL-ем, все равно проще удобнее и правильнее делать в прикладном коде.
А чем хранимки на дотнете не прикладной код? Да еще учитывая возможность генерации их "на лету".
Здравствуйте, Tom, Вы писали:
ili>>отчет? а почему дата-тейбл не подходит? (мне и вправду интересно) Tom>Всегда лучше иметь что то типизированное, а не DataTable
оно, конечно, пожалуй так, но мне вот, не приходилось сталкиваться с проблемами при использовании DataTable для отчетов. тебе (как я понял) приходилось, вот мне и интересно, что там было, дабы на те же грабли не наступать.
Здравствуйте, vdimas, Вы писали:
V>А чем хранимки на дотнете не прикладной код? Да еще учитывая возможность генерации их "на лету".
Обилием проблем с поддержкой и развертыванием. Связываться с этим имеет смысл если App-сервера нет ни в каком виде, а очень нужно, если же хоть какой-то сервер приложений есть, то проще все вынести туда.
V>>А чем хранимки на дотнете не прикладной код? Да еще учитывая возможность генерации их "на лету". IB>Обилием проблем с поддержкой и развертыванием.
Странно, столько доки и примеров на эту тему, что показалось, будто вопрос вполне обыденный.
IB>Связываться с этим имеет смысл если App-сервера нет ни в каком виде, а очень нужно, если же хоть какой-то сервер приложений есть, то проще все вынести туда.
Выражу исключительно моё ИМХО, но выделенный стателесс апп-сервер — это бесполезная прослойка из лишнего процесса, учитывая возможность запихать логику стателесс-алгоритмов прямо в процесс SQL-сервера. А еще когда на этом выделенном апп-сервере начинают кеши когерентные наверчивать, то вообще, спасайся кто может. Причём, кеши эти абсолютно бесполезны, если (как это часто бывает) апп-сервер делают заодно с веб-мордой.
Здравствуйте, vdimas, Вы писали:
V>Странно, столько доки и примеров на эту тему, что показалось, будто вопрос вполне обыденный.
Доками и примерами геморрой не лечится.
V>Выражу исключительно моё ИМХО, но выделенный стателесс апп-сервер — это бесполезная прослойка из лишнего процесса, учитывая возможность запихать логику стателесс-алгоритмов прямо в процесс SQL-сервера.
Ты только геморрой с этим связанный не учитываешь. А учитывая, что App сервер и так есть и причем как правило стейтлесс, то лучше уж логику там держать.
V>А еще когда на этом выделенном апп-сервере начинают кеши когерентные наверчивать,
Это уже не стейтлесс получается.
IB>А учитывая, что App сервер и так есть и причем как правило стейтлесс, то лучше уж логику там держать.
Дык, я и хочу понять — почему это оно "и так есть" до сих пор?
Вернее, я прекрасно знаю, так сложилось из-за того, что императив противопоказан T-SQL, а расчётные формулы бывают изощренные и даже рекурсивные. А еще все любят типизированность, решарпер и XML.
Так же прекрасно помню как плевались юзвери более 10 лет назад, когда ту же самую программу переводили с сетевых MDB-файлов на app-сервера + MS SQL, ибо привыкли получать результат за долю секунды, что глаз не успевал реагировать, а не за 1..2сек. Сейчас не столь актуально, но всё-равно... "лишний" stateless сервак до пол-секунды отклика в среднем добавляет при нагрузке конкретному клиенту (там же две задержки в каждую сторону, два лишних преобразования данных, две лишних межпроцессорных коммуникации). А это на глаз весьма заметно в сравнении с прямым подключением к SQL-серверу, которое отрабатывает субъективно мгновенно на простых выборках (отчёты и прочую сложновычисляемую хрень ввиду не имею, речь о поддержке оперативной набивки/обработки).
И с каких это пор "гемморой" — аргумент? В MS SQL 7 даже колонку, помнится, переименовать в EM сложно было, заводили рядом другую, тут же создавали и запускали запрос копирование столбца, старый дропали, и никто на гемморой не жаловался... И статистику исключительно руками вертели и много еще чего. А сейчас всё тоже самое, только "само", расслабляет наверно?
Самый бенефит, конечно же в том, что этот код в процессе сервера крутится, и в нужных случаях гемморой — не самая большая плата. Мне не очень нравится дизайн System.Data, он совершенно не пригоден для статической типизации, более того, провоцирует своим дизайном на постоянный боксинг примитивных типов, но это всё частности. Я лет еще 5 назад задекларировал "идеальный" для себя апп-сервер, который с базой в одном процессе. Правда, тут Магоммет подошёл, а не гора, но опять же, не суть.
И кстати, в OODB (ничего, что на твой мозоль? я не сильно) есть один такой момент, который многие заметили, но еще большее кол-во предпочло пропустить — это высокая статическая типизированность (для разработчика). Оставь в них только реляционную классику, возьми от них типизированный интерфейс к API сервера при написании своих "хранимок", и получим то, что мне не хватало последние лет 10.
Здравствуйте, vdimas, Вы писали:
V>Дык, я и хочу понять — почему это оно "и так есть" до сих пор?
Очень просто. Каждый должен заниматься своим делом. Вот дело БД — хранить данные, но ни в коем случае не хостить сервера приложений..
V> "лишний" stateless сервак до пол-секунды отклика в среднем добавляет при нагрузке конкретному клиенту (там же две задержки в каждую сторону, два лишних преобразования данных, две лишних межпроцессорных коммуникации).
Я тебя умоляю.. =) По сравнению с латентностью сети и временем обработки запросов БД — это другой порядок малости, в микроскоп не заметишь.
V>Самый бенефит, конечно же в том, что этот код в процессе сервера крутится, и в нужных случаях гемморой — не самая большая плата.
Я тебя разочарую, быстрее он от этого не сильно становится. Я не помню, как там точно SQLOS хостит дотнетные процессы, но именно за счет того что формально это дело хостится в сиквеле выигрыш не большой.
V>Я лет еще 5 назад задекларировал "идеальный" для себя апп-сервер, который с базой в одном процессе.
Ты не стой стороны проблему решаешь. От того что ты все в одно место запихнешь, легче не станет, стабильность и стоимость сопровождения вырастут настолько, что сам рад не будешь.
Если проблема в плохих способах взаимодействия между .Net и БД, значит надо улучшать способ взаимодействия, а не уходить от проблемы запихивая все в одно место.
V>И кстати, в OODB (ничего, что на твой мозоль? я не сильно) есть один такой момент, который многие заметили, но еще большее кол-во предпочло пропустить — это высокая статическая типизированность (для разработчика). Оставь в них только реляционную классику, возьми от них типизированный интерфейс к API сервера при написании своих "хранимок", и получим то, что мне не хватало последние лет 10.
Здравствуйте, IB, Вы писали:
V>> "лишний" stateless сервак до пол-секунды отклика в среднем добавляет при нагрузке конкретному клиенту (там же две задержки в каждую сторону, два лишних преобразования данных, две лишних межпроцессорных коммуникации). IB>Я тебя умоляю.. =) По сравнению с латентностью сети и временем обработки запросов БД — это другой порядок малости, в микроскоп не заметишь.
Латентность сети 100-150ms норма на другой конец земного шара даже из нашей провинции, а про время обработки рассказывать не надо. Оперативные данные — они всегда небольшие по объёму (если правильно делать), в отличие от всевозможных "исторических", но у отчётности, как уже замечал, свои требования и может быть совсем своя огранизация.
V>>Самый бенефит, конечно же в том, что этот код в процессе сервера крутится, и в нужных случаях гемморой — не самая большая плата. IB>Я тебя разочарую, быстрее он от этого не сильно становится. Я не помню, как там точно SQLOS хостит дотнетные процессы, но именно за счет того что формально это дело хостится в сиквеле выигрыш не большой.
V>>Я лет еще 5 назад задекларировал "идеальный" для себя апп-сервер, который с базой в одном процессе. IB>Ты не стой стороны проблему решаешь. От того что ты все в одно место запихнешь, легче не станет, стабильность и стоимость сопровождения вырастут настолько, что сам рад не будешь. IB>Если проблема в плохих способах взаимодействия между .Net и БД, значит надо улучшать способ взаимодействия, а не уходить от проблемы запихивая все в одно место.
Да нет, проблема в том, что мы дублируем описание сущностей, и раздражает в случае сценария stateless — это именно практически 1-в-1 дублирование, чем не обезьянья работа? И про кодогенераторы тоже все знают, как и про разрыв второго рода при рефакторинге.
Далее, существующая бинарная сериализация дотнет крайне неэффективная, медленная и прожорливая в ресурсах, ибо боксит даже примитивные типы, да и вообще создаёт даже для простейших классов кучу промежуточных объектов. Нормальные сравнительные результаты показывает только при сериализации массивов примитивных типов относительно большой длины, в случае же сериализации большого сомна тех самых "типизированных сущностей" — затраты тиков проца только на сериализацию/десериализацию раз в 50 превышают "оптимальную" сериализацию (т.е. то, что примерно делает сервак SQL, и этот порядок замеряли). И вот для тех самых случаев, где требуется большое кол-во мелких выборок для сотен и более клиентов, одни только "нефункциональные" затраты апп-сервака сопоставимы с полезными действиями БД (в "разогретом" состоянии, конечно). Понятное дело, "ставь лишнюю железку и не парься", как все и делают, но как-то это всё попахивает лажей фундаментального плана.
Насчёт "улучшать способ взаимодействия", дык и этим занимался однажды, перелопачивая на ручную сериализацию, где те самые 50 раз в выигрыше и поимел, и заметный субъективный прирост отклика тоже. Но там сущностей было чуть более трёх десятков (правда, структура весьма и весьма развесиста на них), и делалось это уже после "окончательных рефакторингов". А мы то понимаем, как это всё смешно звучит на самом деле. Вот занимаясь такого рода херней, не покидает ощущение какой-то фундаментальной недоработки на ровном месте. Старые добрые OLE DB интерфейсы кажутся гораздо более продуманными в плане эффективного манипулирования данными, чем предложенный System.Data и далее в глубь по нейспейсам.
---------
И просто поверь, когда GUI откликается практически мгновенно, или тормозит секунду-другую, как в браузере, это ОЧЕНЬ большая разница. Привыкнув к первому, с трудом подавляешь раздражение, работая со вторым.
Здравствуйте, vdimas, Вы писали:
V>Латентность сети 100-150ms норма на другой конец земного шара даже из нашей провинции,
И ты хочешь сказать, что передача через границу процесса занимает сравнимое время?
V> а про время обработки рассказывать не надо. Оперативные данные — они всегда небольшие по объёму (если правильно делать),
Какиеб они ни были маленькие — их обработка все равно занимает время большее, чем сериализация объекта в плоскую структуру и обратно.
V>Да нет, проблема в том, что мы дублируем описание сущностей, и раздражает в случае сценария stateless — это именно практически 1-в-1 дублирование, чем не обезьянья работа? И про кодогенераторы тоже все знают, как и про разрыв второго рода при рефакторинге.
Тут ты себе противоречишь.. Ты только что утверждал, что готов на любой геморрой, лишь бы скорость была, а тут выясняется, что проблема все-таки в геморрое..
V>Далее, существующая бинарная сериализация дотнет крайне неэффективная, медленная и прожорливая в ресурсах, ибо боксит даже примитивные типы, да и вообще создаёт даже для простейших классов кучу промежуточных объектов.
А это-то тут причем? Мы вроде только про сиквел беседуем.
V> Нормальные сравнительные результаты показывает только при сериализации массивов примитивных типов относительно большой длины, в случае же сериализации большого сомна тех самых "типизированных сущностей" — затраты тиков проца только на сериализацию/десериализацию раз в 50 превышают "оптимальную" сериализацию (т.е. то, что примерно делает сервак SQL, и этот порядок замеряли). И вот для тех самых случаев, где требуется большое кол-во мелких выборок для сотен и более клиентов, одни только "нефункциональные" затраты апп-сервака сопоставимы с полезными действиями БД (в "разогретом" состоянии, конечно). Понятное дело, "ставь лишнюю железку и не парься", как все и делают, но как-то это всё попахивает лажей фундаментального плана.
То, что стандартный BinarySerializer кривой до нельзя — это факт известный, но я не могу понять, причем тут сиквел и какое это вообще отношение к БД имеет, ты уж не мешай все в одну кучу... Или ты по случаю первого апреля считаешь, что сиквел с приложением посредством стандартной бинарной сериализации типизированных объектов общается? Завязывай, уже второе. =)
V>Насчёт "улучшать способ взаимодействия", дык и этим занимался однажды, перелопачивая на ручную сериализацию, где те самые 50 раз в выигрыше и поимел, и заметный субъективный прирост отклика тоже.
Ну, MS тоже не пальцем деланый — бинарную сериализацию конечно индусы писали, а вот WCF-ные сервисы, в основном все-таки ребята с правильными руками, поэтому, в частности, взаимодействие между процессами посредством WCF сравнимо по скорости с DCOM, так что с сериализацией там все в порядке.
V> Старые добрые OLE DB интерфейсы кажутся гораздо более продуманными в плане эффективного манипулирования данными, чем предложенный System.Data и далее в глубь по нейспейсам.
То есть, ты свою собственную обертку поверх OLDB написал и получил серъезный выигрыш в производительности? "Не верю" (с)
V>И просто поверь,
Просто — не буду.
V>когда GUI откликается практически мгновенно, или тормозит секунду-другую, как в браузере, это ОЧЕНЬ большая разница.
То есть, по твоему браузер тормозит из за того, что IIS выполняется в процессе отдельном от сиквела?
Здравствуйте, IB, Вы писали:
IB>Очень просто. Каждый должен заниматься своим делом. Вот дело БД — хранить данные, но ни в коем случае не хостить сервера приложений..
Кстати, если отбросить геморрой и другие проблемы, то почему бы не хостить сервер приложений в том же процессе, что и сиквел? Производительности и масштабируемости это только помогло бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>>Да нет, проблема в том, что мы дублируем описание сущностей, и раздражает в случае сценария stateless — это именно практически 1-в-1 дублирование, чем не обезьянья работа? И про кодогенераторы тоже все знают, как и про разрыв второго рода при рефакторинге. IB>Тут ты себе противоречишь.. Ты только что утверждал, что готов на любой геморрой, лишь бы скорость была, а тут выясняется, что проблема все-таки в геморрое..
Кому какой ближе, тебе, судя по всему, сопроводительный, мне — в разработке. Хотя, если деплоить базу не скриптами, а маунтить заготовки баз, то как бы гемморроя слегка поменьше (по крайней мере мы деплоим именно так).
IB>То, что стандартный BinarySerializer кривой до нельзя — это факт известный, но я не могу понять, причем тут сиквел и какое это вообще отношение к БД имеет, ты уж не мешай все в одну кучу... Или ты по случаю первого апреля считаешь, что сиквел с приложением посредством стандартной бинарной сериализации типизированных объектов общается? Завязывай, уже второе. =)
Гхм, вообще-то абзацем выше уже был контекст про сервер приложений, так что весь этот абзац к нему и относился. А пихать WCF туда, где 90% банального stateless CRUD, т.е. "прослойка" практически без самостоятельного функционала — это перебор, ИМХО. Такая прослойка должна быть как можно тоньше. Хотя, для ненагрузочных сценариев, чтобы "быстро на коленке собрать", почему бы и нет.
Опять же, а какой избыток данных мы будем гонять на другой конец земного шара, и главное — ради чего?
Хотя, это мы отвлеклись от темы. Просто странный наблюдается парадокс: middleware становится всё мощнее, изощреннее и конфигурируемее, что чуть ли не мышкой серверный код накидывается (утрирую, но оно близко). И чем дальше этот процесс, тем больше народ склоннен "отуплять" СУБД. И нафига тогда кол-во возможностей для построения сервера приложений именно на СУБД растёт с каждым годом? Когда-то рванул Оракл в этом направлении, MS гарцает и даже перегонит скоро, а бывшие аппологеты максимально-внутри СУБД-ориентированной обработки данных уже начинают советовать WCF по каждому чиху. Наверно я опять чего-то не понимаю?
V>>Насчёт "улучшать способ взаимодействия", дык и этим занимался однажды, перелопачивая на ручную сериализацию, где те самые 50 раз в выигрыше и поимел, и заметный субъективный прирост отклика тоже. IB>Ну, MS тоже не пальцем деланый — бинарную сериализацию конечно индусы писали, а вот WCF-ные сервисы, в основном все-таки ребята с правильными руками, поэтому, в частности, взаимодействие между процессами посредством WCF сравнимо по скорости с DCOM, так что с сериализацией там все в порядке.
V>> Старые добрые OLE DB интерфейсы кажутся гораздо более продуманными в плане эффективного манипулирования данными, чем предложенный System.Data и далее в глубь по нейспейсам. IB>То есть, ты свою собственную обертку поверх OLDB написал и получил серъезный выигрыш в производительности? "Не верю" (с)
Нет, я сравниваю инфтерфейсы и способы извлечения данных. Максимально просто и эффективно — да и как по другому в интерфейсах, основная задача которых переливать как можно большее кол-во данных с как можно меньим участием процессора? В противовес этому, на код AdoDB.Net — провайдеров в рефлекторе без слёз смотреть порой невозможно.
Сам сценарий раньше был какой? Заготавливаем источники для всех колонок (смещения или ридеры столбцов), однократно валидируем совпадение типов с ожидаемыми, а потом в цикле тупо льём объемы, и трудоёмкость получается сравнима с memcpy. А сейчас просто пройдись по любому XXXDataReader::ReadIn32(), и ужаснись всей этой безразмерной цепочке кода, которая сопровождает чтение каждого поля каждой строки.
V>>когда GUI откликается практически мгновенно, или тормозит секунду-другую, как в браузере, это ОЧЕНЬ большая разница. IB>То есть, по твоему браузер тормозит из за того, что IIS выполняется в процессе отдельном от сиквела?
Нет, браузер как пример, а тормозит он толи из-за множественных запросов на одну страницу, то ли от природы формирования современных php/jsp/asp страниц, толи еще от чего — не суть, когда гуй не браузерный, то пользователь ожидает адекватную реакцию.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, если отбросить геморрой и другие проблемы, то почему бы не хостить сервер приложений в том же процессе, что и сиквел? Производительности и масштабируемости это только помогло бы.
Это вряд ли, так как если по уму, то один сиквел может держать 3-4 app-сервера, хотя от задач конечно зависит.
Здравствуйте, vdimas, Вы писали:
V>Далее, существующая бинарная сериализация дотнет крайне неэффективная...
А причем тут бинарная сериализация дотнета? Если ты из сервера приложений используешь запросы к сиквелу, то пользуешся его форматом стрима который очень эффективен.
V>Насчёт "улучшать способ взаимодействия", дык и этим занимался однажды, перелопачивая на ручную сериализацию, где те самые 50 раз в выигрыше и ...Старые добрые OLE DB интерфейсы кажутся гораздо более продуманными в плане эффективного манипулирования данными, чем предложенный System.Data и далее в глубь по нейспейсам.
Ты меня извини. Я теоретически с тобой за одно, в том смысле, что тоже считаю, что сервер приложений встроенный в СБУД — это хорошая идея. Но то что ты говоришь — это мягко говоря заблуждения. Причем тут System.Data?
IDataReader самый эффективный способ чтения данных из MS SQL из имеющихся в природе. Никакие OLE DB провайдеры и рядом не валялись.
V>--------- V>И просто поверь, когда GUI откликается практически мгновенно, или тормозит секунду-другую, как в браузере, это ОЧЕНЬ большая разница. Привыкнув к первому, с трудом подавляешь раздражение, работая со вторым.
Кому нужна вера? Есть методы исследования, измерения, тесты...
Создай примитивный тест или просто почитай статьи с этого сайта. В них такие тесты уже делались. Причем много лет назад.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V> Хотя, если деплоить базу не скриптами, а маунтить заготовки баз, то как бы гемморроя слегка поменьше (по крайней мере мы деплоим именно так).
Заготовками баз обратную совместимость не обеспечишь.
V>Гхм, вообще-то абзацем выше уже был контекст про сервер приложений, так что весь этот абзац к нему и относился. А пихать WCF туда, где 90% банального stateless CRUD, т.е. "прослойка" практически без самостоятельного функционала — это перебор, ИМХО. Такая прослойка должна быть как можно тоньше.
Это ты просто WCF не видел, наверное.. =) При желании — тоньше не придумаешь, не вижу никаких проблем запихнуть его всюду, где хоть какая-то передача данных, особенно тупой CRUD.
V> Хотя, для ненагрузочных сценариев, чтобы "быстро на коленке собрать", почему бы и нет.
Как раз с нагрузочными-то никаких проблем.. )
V>Хотя, это мы отвлеклись от темы. Просто странный наблюдается парадокс: middleware становится всё мощнее, изощреннее и конфигурируемее, что чуть ли не мышкой серверный код накидывается (утрирую, но оно близко). И чем дальше этот процесс, тем больше народ склоннен "отуплять" СУБД.
В целом да, но пока я не вижу в этом ничего плохого.
V> а бывшие аппологеты максимально-внутри СУБД-ориентированной обработки данных уже начинают советовать WCF по каждому чиху.
Если это на меня намек, то я всегда был апологетом здравого смысла.. И был одинаково против как всего пихания в базу, так и выпихивания всего из базы. Есть логика связанная чисто с обработкой данных — и это дело БД, и есть бизнес-логика — и с ней в БД делать нечего.
V> А сейчас просто пройдись по любому XXXDataReader::ReadIn32(), и ужаснись всей этой безразмерной цепочке кода, которая сопровождает чтение каждого поля каждой строки.
Ну, допустим, System.Data безбожно кривой. Мой поинт в том, что надо лечить System.Data, а не засовывать все в один процесс.
V>Нет, браузер как пример, а тормозит он толи из-за множественных запросов на одну страницу, то ли от природы формирования современных php/jsp/asp страниц, толи еще от чего — не суть, когда гуй не браузерный, то пользователь ожидает адекватную реакцию.
Так, ты считаешь, что сейчас проблемы сделать нормальную реакцию на UI в распределенном приложении и они решатся, если прикладной код будет исполняться в одном процессе с БД?
Здравствуйте, VladD2, Вы писали:
VD>А что вызывает геморрой? Если, можно по конкретнее.
Геморрой вызывает отладка, сопровождение, тестирование и развертывание. Начиная от того, что сборки надо регистрировать в сиквеле, и заканчивая тем, что ДБА и разработчики дотнетного кода — несколько разные люди, хорошо квалифицированные в своей области, но имеющие довольно слабые представления о другой.
Моя последняя попытка использовать это на практике воспитала во мне очень серьезный скепсис к подобного рода решениям.
VD>А причем тут бинарная сериализация дотнета? Если ты из сервера приложений используешь запросы к сиквелу, то пользуешся его форматом стрима который очень эффективен.
Я имел ввиду способ связи с сервером приложений; разумеется, формат данных SQL-сервера гораздо эффективнее, т.е. о том и речь, что эффективнее напрямую к SQL подключаться не только из-за отсутствия лишней прослойки, но так же из-за формата данных. Есть, конечно, еще более эффективные форматы данных — это CORBA или даже ASN.1, но они требуют дополнительной спецификации интерфейса.
V>>Насчёт "улучшать способ взаимодействия", дык и этим занимался однажды, перелопачивая на ручную сериализацию, где те самые 50 раз в выигрыше и ...Старые добрые OLE DB интерфейсы кажутся гораздо более продуманными в плане эффективного манипулирования данными, чем предложенный System.Data и далее в глубь по нейспейсам.
VD>Ты меня извини. Я теоретически с тобой за одно, в том смысле, что тоже считаю, что сервер приложений встроенный в СБУД — это хорошая идея. Но то что ты говоришь — это мягко говоря заблуждения. Причем тут System.Data?
VD>IDataReader самый эффективный способ чтения данных из MS SQL из имеющихся в природе. Никакие OLE DB провайдеры и рядом не валялись.
Нет, это не так. И я имею ввиду не классическое ADO над OLE DB, и тем паче не ADO.Net OLE DB provider, именно сами OLE DB интерфейсы, которые весьма и весьма продуманны для целей эффективного взаимодействия. Показательно то, что в начале OLE DB провайдеры для многих баз делали как обертки над ODBC, но затем, "проникнувшись" стали поступать ровно наоборот.
Согласен лишь с тем, что, написав парсер стрима MS SQL прямо в дотнет, они немного выиграли. Но никто не предоставил такого сценария работы, когда валидирование типов колонок производится лишь однажды, и затем результат парсинга непосредственно куда-то льётся без тонны проверок на каждом поле. Для подобного сценария помогло бы нечто вроде инверсии, наподобии DabaAdapter.FillTable(table), только нужен типизированный вариант, а не тупое GetValues(object[] values) на каждую строчку.
Сегодня ситуация такова, что затраты на приседания вокруг извлечения готового значения поля данных чуть ли не на порядок выше, чем затраты парсера стрима SQL на его разбор.
V>>--------- V>>И просто поверь, когда GUI откликается практически мгновенно, или тормозит секунду-другую, как в браузере, это ОЧЕНЬ большая разница. Привыкнув к первому, с трудом подавляешь раздражение, работая со вторым.
VD>Кому нужна вера? Есть методы исследования, измерения, тесты...
Есть много чего. Если ты собрался субъективные ощущения переводить в цифры, то я могу дать ориентировочные отправные данные — это примерно 0.5 сек для субъективно "быстрого" отклика GUI, выше примерно 1.5 сек начинает уже раздражать.
Ты вообще видел хоть раз, как девочки накладные настукивают в сотни (иногда до пары тысяч) строк?
VD>Создай примитивный тест или просто почитай статьи с этого сайта. В них такие тесты уже делались. Причем много лет назад.
Здравствуйте, IB, Вы писали:
V>>Гхм, вообще-то абзацем выше уже был контекст про сервер приложений, так что весь этот абзац к нему и относился. А пихать WCF туда, где 90% банального stateless CRUD, т.е. "прослойка" практически без самостоятельного функционала — это перебор, ИМХО. Такая прослойка должна быть как можно тоньше. IB>Это ты просто WCF не видел, наверное.. =) При желании — тоньше не придумаешь, не вижу никаких проблем запихнуть его всюду, где хоть какая-то передача данных, особенно тупой CRUD.
Как может XML быть тоньше того же ASN.1, например? (формат стрима от MS SQL близок по духу)
Я может, скажу громко, но использование СУБД настолько широко сейчас, что ко многим сценариям обобщённое требование звучит как "реалтайм". Дык, надо от туда и брать наработки.
V>> а бывшие аппологеты максимально-внутри СУБД-ориентированной обработки данных уже начинают советовать WCF по каждому чиху. IB>Если это на меня намек, то я всегда был апологетом здравого смысла.. И был одинаково против как всего пихания в базу, так и выпихивания всего из базы. Есть логика связанная чисто с обработкой данных — и это дело БД, и есть бизнес-логика — и с ней в БД делать нечего.
Есть мнение, что эта граница весьма нечёткая, а по мне — так её нет в принципе, ну разве что выбираемыми абстракциями мы можем лишь условно её проводить. Для своего успокоения, ну типа всё у нас декомпозированно по последнему слову техники: там персисент, а там БЛ.
Ну смешно, право, считать, что вычисляемый столбец в каком-либо запросе — это далеко от бизнес-логики... я уже молчу об агрегатах.
IB>Ну, допустим, System.Data безбожно кривой. Мой поинт в том, что надо лечить System.Data, а не засовывать все в один процесс.
... IB>Так, ты считаешь, что сейчас проблемы сделать нормальную реакцию на UI в распределенном приложении и они решатся, если прикладной код будет исполняться в одном процессе с БД?
Нет, конечно, тут нужен комплекс мер. Просто реализация "бизнес-логики" в виде sored procecure решает сразу два пункта из этого комплекса: убирает 2 лишние сериализации (заметь — самые неэффективные из всей цепочки), а так же лишний слой межпроцессного взаимодействия (который на современных ОС не эффективен по фундаментальным причинам).
Согласись, что СУБД изначально стали выносить за пределы приложений с целью обеспечения безопасности данных путём такого изолирования. Управляемые среды с валидируемым кодом, ИМХО, решают эту проблему. Сейчас связь с этими stored proc на .Net не самая эффективная, на основе "того что было" (System.Data), если народ будет этим повсеместно пользоваться, то возникнет требование более легковесного и типизированного решения, которое вполне может быть реализовано MS.
Мы уже победили, просто это еще не так заметно...
