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