Как стать автором
Обновить

Комментарии 13

Не хочется быть токсиком, но очень хотелось бы узнать, в чем смысл данной статьи?

Мне кажется практически любой дотнет разработчик знает про ADO и EF и как с ними работать.

Были бы может быть интересны попытки архитектурного осмысления, в каких именно сценариях лучше всего использовать те или иные провайдеры. Но нет, тут какой-то сферический тест в вакууме.

Цель данной статьи - написать общий туториал, который начинающие разработчики смогут применить где-то у себя.

Статья не предусмотрена для более опытных разработчиков, и они вряд ли узнают здесь что-то новое.

Касательно более реальных тестов - такая идея есть, и возможно в скором времени появится и такое расширение для данной статьи.

А что, в интернете нет туториалов по данному вопросу? Почему новичок будет читать информацию здесь, а не на метанит или msdn? Да и вообще, какая вероятность, что он как-то попадет на хабр, этот новичок?

Из своего опыта могу сказать что новую инфу часто гуглю на хабре. Изложение информации часто бывает более доступно тут, чем на официальных туториалах. Думаю, в этой статье выжимка материала аналогична нескольким главам на metanit, что позволяет получить более общую картину работы с провайдерами данных.

Я нерегулярно пишу статьи в бложик в вконтактике, и с большой уверенностью могу сказать что статья писалась быстро и "чтобы было". Присутствует все: вымученность, связанные с этим смысловые ошибки, ошибки в терминах, отсутствие какой либо системы и тд. Я так пишу, когда нахожу хорошую статью на перевод (или цикл статей для компиляции и перевода) или пишу авторскую, но в процессе понимаю, что откусил больше, чем могу проглотить. Соответственно текст начинает урезаться и получается какая-то херня. Правильным решением в данном случае является разделение темы на серию отдельных публикаций.

В данном случае, так как я пользовался MS SQL Server, то использовать Microsoft SQL Server Managment Studio (SSMS) является лучшим решением. При использовании, допустим, PostgreSQL можно использовать PG Admin в качестве СУБД.

Что я только что прочитал? MS SQL Server и PostgreSQL — это и есть СУБД. А SSMS и PG Admin — это не СУБД, а графические клиенты к ним.


Поэтому, когда говорим об ADO.NET — это провайдер, EntityFramework (EF) — ORM, а Dapper — micro-ORM.

Только вот ADO.NET — это не провайдер.


Необходимо наличие следующих пакетов: System.Data.SqlClient

А вот и нет. System.Data.SqlClient — это клиент-провайдер для MS SQL Server, и его частью являются классы вроде SqlConnection


Неотъемлемой частью ADO.NET они не являются.


Первое, что мы делаем — создаем объект класса SqlConnection, в который передаем connectionString, эта переменная в которой содержится строка подключения к нашей базе

Вот тут остро не хватает информации о том, как такие строки составлять. А также ссылки на https://www.connectionstrings.com/


В try открываем соединение, в finally его закрываем

То, что соединения нужно закрывать — это полезная информация, но новичкам было бы неплохо рассказать и про конструкцию using.


То же самое замечание применимо и для наследников DbReader.

Спасибо за конструктивную критику! И отдельное спасибо за предоставление ресурса по строкам подключения.

Касательно использования using - то пример его использования есть в рассказе про Dapper, хотя и без объяснения того, что using представляет собой try finally.

В EF есть общее правило - коллекции объектов, которые соответствуют таблицам базы данных, называть существительным во множественном числе.
Для примера, приведенного в этой статье вместо

public DbSet<Student> Student { get; set; }

следует использовать

public DbSet<Student> Students { get; set; }

То есть Students это коллекция объектов типа Student.

Да, верно! Это правило используется не только в рамках EF, но и в правиле именования всех коллекций (VS сама подсказывает так сделать). Но так как изначально таблицы именовались именно так, то, для сохранения однотипности коллекции были названы в единственном числе.

Ну, чисто в теории можно, есть еще старенькие проекты, использующие файловую систему, идею которых можно еще увидеть в университетских лабораторных по сей день.

Какое сильное, но ничем не обоснованное, утверждение. В десктопе большинство софта будет работать без БД, будь то офисный пакет, смотрелки всяких файлов, файловый менеджер, архиваторы, VPN клиент... Имя им легион.

С уровнем промашка. Ответ на сообщение выше.

Плюсую. Для многих приложений уровня "утилита" использование БД избыточно. Чего ради авторы притягивают аргументы за уши неясно.

Про офисный пакет -- смотря что в него включать. В M365, например, помимо использования "родного" движка jet/ace в почтовом клиенте, есть/наполняются файлы sqlite. Вопрос для чего, и как такое вышло мне не даёт покоя.

Категорично как-то написано

На самом деле на платформе .NET есть три основных решения для данной ситуации (в реальности их будет и больше, скорее всего, но реально поддерживаемых, стабильных и проверенных только три).

Мне вот нравится библиотека linq2db

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории