Comments 51
UFO just landed and posted this here
норм, только можно было вместо текстбокса вставить грид — человечнее бы смотрелось
и, что любопытно, на потребление памяти (если использовать winForms вместо WPF) не сильно бы повлияло, и места на диске скомпиленная апликуза бы больше не заняла. зато к «Но в 1989 году я бы потратил месяц» можно было бы смело накинуть еще годик(а то пяток чтобы дождаться до выхода win95) на реализацию грида :D
Извините, но на прикрутку грида в WPF я бы потратил довольно много времени, чего мне совершенно не хотелось. Я на работе пишу под ASP.Net, и WPF для меня не совсем «родная» технология.
Хотели показать без монстров, но WPF всё-таки прикрутили.
Я понимаю что нехорошо сравнивать апельсины с крокодилами, но, имхо, консольная версия как главная была бы более уместна.
Я понимаю что нехорошо сравнивать апельсины с крокодилами, но, имхо, консольная версия как главная была бы более уместна.
Я так и хотел сначала, но потом все же решил, что уместнее будет использовать форму с кнопочками и текстбоксами. А WPF ИМХО менее монструозен, чем Windows.Forms. Это как раз пример того, что более новая и совершенная технология может быть проще и дружественнее предыдущей.
Да ну, WPF куда проще и элегантнее WinForms. В том числе по внутренней архитектуре.
Уже появились .net разработчики которые без Entity FrameWork работать не умеют? Или это только один wizard такой?
Да нет, просто разработчикам не шибко интересно читать статьи по System.Data.SQLClient, потому что он простой и его все знают.
Это как ажиотаж по поводу навороченных коммуникаторов — все знают, что топ — это склоки, холиворы, статьи, описание, интерес, разработка, развитие, но никто не смотрит за тем, что Нокия выпустила очередной кирпичефон с десятью кнопками, вызовом и монохромным экраном.
Никто на это не смотрит, потому что ВСЕ уверены в том, что это есть 8-)
Это как ажиотаж по поводу навороченных коммуникаторов — все знают, что топ — это склоки, холиворы, статьи, описание, интерес, разработка, развитие, но никто не смотрит за тем, что Нокия выпустила очередной кирпичефон с десятью кнопками, вызовом и монохромным экраном.
Никто на это не смотрит, потому что ВСЕ уверены в том, что это есть 8-)
Забавно, я-то думал, вы сейчас предложите работу с бд в стиле ado, или ещё что-нибудь более низкоуровневое. Я не ругаюсь, но лично мне, не понятно, в чём фишка статьи. Уверен, .net-разработчики очень даже в курсе этих элементарных вещей, ибо это основы.
Разработчики — да. А вот те, кто только может собираться ими стать — нет. Да еще и пишут о том, какой плохой .Net — им нужно прогнать два-три запроса к базе данных, а оно им создает кучу датасетов, контекстов, сущностей и всякой другой бяки, с которой они не имеют понятия что делать.
Статья скорее не про дотнет, а про философию разработки. А описанный пример — наверное самый низкий уровень, на который доводится опускаться в 99.9% реальных проектов.
Статья скорее не про дотнет, а про философию разработки. А описанный пример — наверное самый низкий уровень, на который доводится опускаться в 99.9% реальных проектов.
А реально сделать подключаемую библиотеку к программе для работы с, например, access. (для того что бы не устанавливать провайдер в ОС)
WPF упорно не вяжется с основной идеей статьи. Вы вернулись к низам SQL а используете для фейса один из самых навороченных фреймворков в мире 8-).
Собственно говоря, я о чём? Это не особо низкоуровнево. 90% всех фреймворков для .NET построены на этой технологии. Более того, я лично написал 2 фреймворка для работы с БД, которые щас есть в продакшине, на основе SQLClient. В основном всё это дописывается с целью получить методы типа SelectRow(), ExecuteAndRetutnSingleValue
Собственно говоря, я о чём? Это не особо низкоуровнево. 90% всех фреймворков для .NET построены на этой технологии. Более того, я лично написал 2 фреймворка для работы с БД, которые щас есть в продакшине, на основе SQLClient. В основном всё это дописывается с целью получить методы типа SelectRow(), ExecuteAndRetutnSingleValue
{чёта какие-то лаги...}
Вы устремили свой взгляд не на низкоуровневый клиент, а на базовый клиент .NET
C помощью него пишутся остальные фреймворки, именно для того, чтобы не мучаться потом с нетипизированными датасетами, и написанием миллиардов тривиальных запросов. И как показала моя практика… В серьёзных проектах всё начинается с фреймворка для базы, самописного или существующего. Никто не будет шарашить проект только на SqlClient, а выучить его — это секундное дело.
Вы устремили свой взгляд не на низкоуровневый клиент, а на базовый клиент .NET
C помощью него пишутся остальные фреймворки, именно для того, чтобы не мучаться потом с нетипизированными датасетами, и написанием миллиардов тривиальных запросов. И как показала моя практика… В серьёзных проектах всё начинается с фреймворка для базы, самописного или существующего. Никто не будет шарашить проект только на SqlClient, а выучить его — это секундное дело.
Там еще консольная версия есть. В архиве ;)
О том, что SQLClient вовсю используется в качестве основы для фреймоворков, которые работают с БД я тоже знаю и не понаслышке — три из трех коммерческих проектов, в разработке которых я принимал участие используют именно его. Статья для студентов, которые не знают о них и упорно используют «экскаваторы для рытья ямок» в своих курсовых/дипломах да еще и ругают дотнет за то, что он видите ли «не дает сделать прямой запрос к БД». Если вы поверхностно пройдетесь по и-нету в поисках того, как средствами дотнета можно работать с БД, то увидите, что 90% материала посвящены ADO.Net Datasets, LINQ2SQL и EF. Собственно, новички и клюют на это, а потом матерятся из-за того, что с самого начала выбрали не тот инструмент, который им нужен.
О том, что SQLClient вовсю используется в качестве основы для фреймоворков, которые работают с БД я тоже знаю и не понаслышке — три из трех коммерческих проектов, в разработке которых я принимал участие используют именно его. Статья для студентов, которые не знают о них и упорно используют «экскаваторы для рытья ямок» в своих курсовых/дипломах да еще и ругают дотнет за то, что он видите ли «не дает сделать прямой запрос к БД». Если вы поверхностно пройдетесь по и-нету в поисках того, как средствами дотнета можно работать с БД, то увидите, что 90% материала посвящены ADO.Net Datasets, LINQ2SQL и EF. Собственно, новички и клюют на это, а потом матерятся из-за того, что с самого начала выбрали не тот инструмент, который им нужен.
Ну всё таки, ну не поверю я, что чисто физически сейчас можно найти человека, который не имеет ни малейшего представления о DataSet, зная о том, что такое SQL. Если это проводить как отдельный цикл, то просто всё хаброобщество укажет, что на МСДН есть одна страничка, которая полностью раскрывает все возможности клайента.
Поэтмоу и пишут про ANEF итп, потому что они неизвестны! А тайна — это то, что больше всего привлекает существ на этой планете 8-)))
Поэтмоу и пишут про ANEF итп, потому что они неизвестны! А тайна — это то, что больше всего привлекает существ на этой планете 8-)))
Ну почему же… Со стыдом и смехом признаюсь, что года три назад, на втором курсе, я писал курсовую работу с помощью датасетов просто потому, что даже не знал о существовании SQLClient. Просто потому, что до того писал всякую ерунду на С++, а про C# ходили разговоры, что он проще и даже документацию читать не надо, а для работы с БД нужно использовать только датасеты. Естественно, получилась полная ерунда, которая, впрочем побудила меня прочитать пару книг про дотнет и пойти на работу именно .Net-разработчика. А с SQLClient я в результате столкнулся аж на работе и понял как его использовать за несколько минут. Студенты, пишущие софт, вообще очень интересные зверьки =)
Кстати, спасибо, заменил в названии слово «низкоуровневый» на «базовый».
Это юмор что-ли такой новомодный. О чём статья вообще, неужели о подсоединённых и отсоединённых объектах. Но ведь любой кто учит ADO.NET, по идее сразу с этим сталкивается, это первая глава любой книги по этой технологии. В MSDN сразу об этом написано.
Отсоединённые объекты
ExecuteReader, ExecuteScalar — запросы SELECT
ExecuteNonQuery — запросы UPDATE, INSERT и DELETE
Отсоединённые объекты
ExecuteReader, ExecuteScalar — запросы SELECT
ExecuteNonQuery — запросы UPDATE, INSERT и DELETE
Это для совсем домохозяек? :)
BTW, это все можно написать в 2 строчки без всяких WTF.
BTW, это все можно написать в 2 строчки без всяких WTF.
С точки зрения перлового базового DBI это всё какая-то лишняя суета.
UFO just landed and posted this here
Полностью согласен.
Нет рейтинга для кармы )
Нет рейтинга для кармы )
Я вижу тыщу причин работать с SQL напрямую, когда работаешь с WinForms, и две тыщи причин работать с SQL напрямую, когда пишешь приложения на ASP.NET. Даже если ты знаешь Linq2SQL.
ИМХО изучение новых технологий — дело хорошее и перспективное, но, изучая новые фреймворки, программисты забы(и)вают (на) более низкоуровневые вещи, знать которые не просто нужно, но еще и важно. Иначе, в конечном итоге все программирование сведется к фразе «я и колеса попинал, и стекло протер, а все равно не заводится». Также как пилоты сейчас, с выходом разных эрбасов-320 и последних боингов — в большинстве своем операторы самолета, и за штурвал тянут раз в пятилетку, когда надо классность подтвердить для записи в книжечку. Хотите в такие программисты?
ИМХО изучение новых технологий — дело хорошее и перспективное, но, изучая новые фреймворки, программисты забы(и)вают (на) более низкоуровневые вещи, знать которые не просто нужно, но еще и важно. Иначе, в конечном итоге все программирование сведется к фразе «я и колеса попинал, и стекло протер, а все равно не заводится». Также как пилоты сейчас, с выходом разных эрбасов-320 и последних боингов — в большинстве своем операторы самолета, и за штурвал тянут раз в пятилетку, когда надо классность подтвердить для записи в книжечку. Хотите в такие программисты?
>Я вижу тыщу причин работать с SQL напрямую, когда работаешь с WinForms, и две тыщи причин работать с SQL напрямую, когда пишешь приложения на ASP.NET. Даже если ты знаешь Linq2SQL.
Озвучьте, плз!
>ИМХО изучение новых технологий — дело хорошее и перспективное, но, изучая новые фреймворки, программисты забы(и)вают (на) более низкоуровневые вещи, знать которые не просто нужно, но еще и важно.
Не вижу связи. Ну, изучил я linq2sql — вс, tsql мне недоступен?
Озвучьте, плз!
>ИМХО изучение новых технологий — дело хорошее и перспективное, но, изучая новые фреймворки, программисты забы(и)вают (на) более низкоуровневые вещи, знать которые не просто нужно, но еще и важно.
Не вижу связи. Ну, изучил я linq2sql — вс, tsql мне недоступен?
На всю тыщу место переводить не буду :) Тем более что я утрировал, и это можно было понять. Но веские причины есть, и как минимум одна из них — производительность. Поглядите тесты производительности различных способов доступа к БД из .NET, их полно в сети. LinQ — стопроцентный аутсайдер в ASP.NET приложениях, хотя и слегка отыгрывается в WinForms.
Что же касается связи, то я ее вижу. Вы сами сказали, что изучили Linq2SQL и не видите причин работать с SQL напрямую. Что тогда толку с того, что T-SQL доступен, Вы ведь его не будете использовать. Смысла ведь нет.
Думаю, никто не будет спорить, что различные фреймворки, хоть и здорово облегчают жизнь, но обязательно сказываются на чем-то ином. По крайней мере те, что майкрософт выдает :), не буду говорить о руби или пхп, не особо силен.
В любом случае, каждый делает как ему удобно. И выбирает, соответственно, что ему нужно — скорость разработки приложения или скорость работы приложения.
Прошу прощения за много букв :)
Что же касается связи, то я ее вижу. Вы сами сказали, что изучили Linq2SQL и не видите причин работать с SQL напрямую. Что тогда толку с того, что T-SQL доступен, Вы ведь его не будете использовать. Смысла ведь нет.
Думаю, никто не будет спорить, что различные фреймворки, хоть и здорово облегчают жизнь, но обязательно сказываются на чем-то ином. По крайней мере те, что майкрософт выдает :), не буду говорить о руби или пхп, не особо силен.
В любом случае, каждый делает как ему удобно. И выбирает, соответственно, что ему нужно — скорость разработки приложения или скорость работы приложения.
Прошу прощения за много букв :)
++ вам в карму.
>Поглядите тесты производительности различных способов доступа к БД из .NET, их полно в сети. LinQ — стопроцентный аутсайдер в ASP.NET приложениях, хотя и слегка отыгрывается в WinForms.
Что-то вы не то пишете…
В большинстве случаев linq2sql генерит вплоне понятные нормальные запросы. Если, разумеется, не зниматься экономией на спичках типа «в select перечисляются все поля, это сильно увеличивает трафик» и подобным идиотизмом(уж извините за резкое слово).
>Что же касается связи, то я ее вижу. Вы сами сказали, что изучили Linq2SQL и не видите причин работать с SQL напрямую. Что тогда толку с того, что T-SQL доступен, Вы ведь его не будете использовать. Смысла ведь нет.
Смысл есть. В достаточно редких случаях.
Под «работать с sql напрямую» я имею в виду вызов хранимки, разумеется.
В общем — не убедили :)
Что-то вы не то пишете…
В большинстве случаев linq2sql генерит вплоне понятные нормальные запросы. Если, разумеется, не зниматься экономией на спичках типа «в select перечисляются все поля, это сильно увеличивает трафик» и подобным идиотизмом(уж извините за резкое слово).
>Что же касается связи, то я ее вижу. Вы сами сказали, что изучили Linq2SQL и не видите причин работать с SQL напрямую. Что тогда толку с того, что T-SQL доступен, Вы ведь его не будете использовать. Смысла ведь нет.
Смысл есть. В достаточно редких случаях.
Под «работать с sql напрямую» я имею в виду вызов хранимки, разумеется.
В общем — не убедили :)
>В большинстве случаев linq2sql генерит вплоне понятные нормальные запросы. Если, разумеется, не зниматься экономией на спичках типа «в select перечисляются все поля, это сильно увеличивает трафик» и подобным идиотизмом(уж извините за резкое слово).
Судя по этой фразе, Вы не вполне различаете понятия «понятные запросы» и «быстрые запросы». После этой фразы у меня сложилось мнение, что вы не совсем понимаете, как приложение взаимодействует с БД. Хотя, возможно, я и ошибаюсь.
Я не спорю, что LinQ прост и понятен «в обслуживании». Но он тормозной.
Что же касается вызова хранимой процедуры — тут по барабану, кто ее вызывает, но дело в том, что она отрабатывает на SQL-сервере, а не в приложении, и поэтому не играет никакой роли в проводимом тут сравнении. Основная проблема как раз в том слое приложения, которое отвечает за доступ к БД.
И микроскопом можно гвозди забивать, но стоит в роли гвоздя выступить шурупу, как микроскоп становится излишеством. Аминь :)
Судя по этой фразе, Вы не вполне различаете понятия «понятные запросы» и «быстрые запросы». После этой фразы у меня сложилось мнение, что вы не совсем понимаете, как приложение взаимодействует с БД. Хотя, возможно, я и ошибаюсь.
Я не спорю, что LinQ прост и понятен «в обслуживании». Но он тормозной.
Что же касается вызова хранимой процедуры — тут по барабану, кто ее вызывает, но дело в том, что она отрабатывает на SQL-сервере, а не в приложении, и поэтому не играет никакой роли в проводимом тут сравнении. Основная проблема как раз в том слое приложения, которое отвечает за доступ к БД.
И микроскопом можно гвозди забивать, но стоит в роли гвоздя выступить шурупу, как микроскоп становится излишеством. Аминь :)
Кстати, небольшая ремарка по поводу WPF. В данном случае (пример на скорую руко) вполне оправдано использование абсолютного позиционирования, но в принципе на мой взгляд совершенно напрасно Microsoft задал в конструкторе форм поведение, при котором добавляемые на форму компоненты автоматически позиционируются в стиле Width, Height, Margin. Понятно, что это сделано для совместимости, чтобы не вызывать когнитивный диссонанс у впервые работающего в WPF, но ИМХО довольно спорный метод для немного знающего об основных контейнерных контролах.
Может быть я ошибаюсь, и в VS2008 можно настроить редактор форм так, чтобы без абсолютного позиционирования было?
Может быть я ошибаюсь, и в VS2008 можно настроить редактор форм так, чтобы без абсолютного позиционирования было?
ощущаю себя стареющим…
За текст до ката ++ Вам в карму. Остальное не читал, так как с .NET не работаю.
Ну использовали вы классический ADO.NET. Пнули LINQ2SQL и EF. А где собственно сравнение — чем хуже для получения тех же двух строк использовать LINQ2SQL? Памяти больше? Медленнее? Разработка сложнее?
А использование ORM фреймворков — как раз очень правильная практика. Потому что некий DataReader — не несет в себе семантической нагрузки. А вот вот полученная из базы выборка объектов User с полем FIO — уже представляет практический интерес. И использовать можно даже не для «больших» проектов. Чтобы не заморачиваться с SQL запросами, Reader'ами…
ЗЫ Когда не было ни LINQ2SQL, ни EF — так и приходилось юзать ADO.NET. И че-то было нифига неудобно — с радостью пересел на LINQ, а потом и на EF
А использование ORM фреймворков — как раз очень правильная практика. Потому что некий DataReader — не несет в себе семантической нагрузки. А вот вот полученная из базы выборка объектов User с полем FIO — уже представляет практический интерес. И использовать можно даже не для «больших» проектов. Чтобы не заморачиваться с SQL запросами, Reader'ами…
ЗЫ Когда не было ни LINQ2SQL, ни EF — так и приходилось юзать ADO.NET. И че-то было нифига неудобно — с радостью пересел на LINQ, а потом и на EF
Вы, возможно, не до конца поняли цель статьи. Основная мысль высказана до хабраката — о том, когда и зачем нужно использовать фреймворки. А пример использования SQLClient — всего лишь подсказка некоторому, очень небольшому, числу программистов, пишущих на .Net, что кроме фреймворков существуют и более простые способы работы с БД.
Собственно топик просто ответ на высказывания:
Самое худшее то, что так считает не один и не два человека, и как результат оно негативно влияет на имидж дотнета и других современных технологий — создается мнение, что они сложны, тормознуты и вообще тру-кодеры должны писать только на языке Х.
Собственно топик просто ответ на высказывания:
Это работа с БД в C#. Сам алгоритм весьма крив, памяти много ест, много промежуточный действий. И всё ради того, чтобы получить пару строк данных. А прямой зарос написать нельзя. Неположено т.к. небезопасно.
Мы с другом писали его дипломник на шарпах на ВМиК. Это раз.
Второе: Опишите БД, опишите коннектор (Ага, вот и начнётся веселье), опишите форму работы (ну хоть что-то она должна выводить и куда-то), взвести после этого работающий проект, который с локалхоста mssql2000 из любой базы запрашивает строку и выводит её на экран. После этого взвесте папку проекта. После взвешивания запустите приложение и посмотрите, сколько оперативной памяти оно потребит. А после этого уже тыкайте в лицо классом, которому для работы нужно проделать очень много работы.
Самое худшее то, что так считает не один и не два человека, и как результат оно негативно влияет на имидж дотнета и других современных технологий — создается мнение, что они сложны, тормознуты и вообще тру-кодеры должны писать только на языке Х.
Ну да, в свете таких заявлений статья будет полезной :)
Но я все равно считаю, что использование чистого SQL мало когда оправдано. Повышение производительности на 5-10%? Сомнительная плата за возможность выявления ошибок в запросе на этапе компиляции, мощный объектный маппинг, наглядность и удобство разработки.
А нытье про память и объем на винте — где то был очень правильный коммент. Раньше программа запускалась на компе с 1Мб памяти — и занимала 512 Кб = 50%. Сейчас запускается на компе с 1Гб ОЗУ и забирает 10Мб = 1%. Прогресс налицо ;)
Но я все равно считаю, что использование чистого SQL мало когда оправдано. Повышение производительности на 5-10%? Сомнительная плата за возможность выявления ошибок в запросе на этапе компиляции, мощный объектный маппинг, наглядность и удобство разработки.
А нытье про память и объем на винте — где то был очень правильный коммент. Раньше программа запускалась на компе с 1Мб памяти — и занимала 512 Кб = 50%. Сейчас запускается на компе с 1Гб ОЗУ и забирает 10Мб = 1%. Прогресс налицо ;)
Да, конечно хотелось бы видеть сравнение Ling2SQL и классику жанра, но все равно спасибо :) Хотя сразу скажу что + от классики в том что не нужно обновляться до 3его с половиной фреймворка :) (это же страшна :))
Я студент. Тем не менее делал именно так с самого начала. =)
В свое студенческое время, я стараюсь научиться чему-то без использования всяких сторонних фреймворков и даже компонент.
Может быть это не совсем правильно, но мне почему-то хочется научиться пользоваться стандартными средствами, а уж потом расширить свои знания и фреймворками и допольнительными компонентами.
В свое студенческое время, я стараюсь научиться чему-то без использования всяких сторонних фреймворков и даже компонент.
Может быть это не совсем правильно, но мне почему-то хочется научиться пользоваться стандартными средствами, а уж потом расширить свои знания и фреймворками и допольнительными компонентами.
хз почему эти студенты ищут материалы по технологиям(nhibernate, linq, adonet) а потом ругают платформу (net framework).
думаю если они нормально поизучают фреймворк, то как раз и увидят, что можно обращаться к БД напрямую.
а статья непонятно зачем написана. о том как обращаться к бд написано очень много(я про sqlclient)
думаю если они нормально поизучают фреймворк, то как раз и увидят, что можно обращаться к БД напрямую.
а статья непонятно зачем написана. о том как обращаться к бд написано очень много(я про sqlclient)
Sign up to leave a comment.
Взаимодействие с базой данных на базовом уровне без привлечения специализированных фреймворков.