Комментарии 13
Не хочется быть токсиком, но очень хотелось бы узнать, в чем смысл данной статьи?
Мне кажется практически любой дотнет разработчик знает про ADO и EF и как с ними работать.
Были бы может быть интересны попытки архитектурного осмысления, в каких именно сценариях лучше всего использовать те или иные провайдеры. Но нет, тут какой-то сферический тест в вакууме.
Цель данной статьи - написать общий туториал, который начинающие разработчики смогут применить где-то у себя.
Статья не предусмотрена для более опытных разработчиков, и они вряд ли узнают здесь что-то новое.
Касательно более реальных тестов - такая идея есть, и возможно в скором времени появится и такое расширение для данной статьи.
А что, в интернете нет туториалов по данному вопросу? Почему новичок будет читать информацию здесь, а не на метанит или msdn? Да и вообще, какая вероятность, что он как-то попадет на хабр, этот новичок?
Из своего опыта могу сказать что новую инфу часто гуглю на хабре. Изложение информации часто бывает более доступно тут, чем на официальных туториалах. Думаю, в этой статье выжимка материала аналогична нескольким главам на metanit, что позволяет получить более общую картину работы с провайдерами данных.
Я нерегулярно пишу статьи в бложик в вконтактике, и с большой уверенностью могу сказать что статья писалась быстро и "чтобы было". Присутствует все: вымученность, связанные с этим смысловые ошибки, ошибки в терминах, отсутствие какой либо системы и тд. Я так пишу, когда нахожу хорошую статью на перевод (или цикл статей для компиляции и перевода) или пишу авторскую, но в процессе понимаю, что откусил больше, чем могу проглотить. Соответственно текст начинает урезаться и получается какая-то херня. Правильным решением в данном случае является разделение темы на серию отдельных публикаций.
Вот вам общий туториал, наверное лучшее что я видел (тыкать по сценариям использования)
https://tortugaresearch.github.io/DotNet-ORM-Cookbook/ORMs.htm
В данном случае, так как я пользовался 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.
В EF есть общее правило - коллекции объектов, которые соответствуют таблицам базы данных, называть существительным во множественном числе.
Для примера, приведенного в этой статье вместо
public DbSet<Student> Student { get; set; }
следует использовать
public DbSet<Student> Students { get; set; }
То есть Students это коллекция объектов типа Student.
Ну, чисто в теории можно, есть еще старенькие проекты, использующие файловую систему, идею которых можно еще увидеть в университетских лабораторных по сей день.
Какое сильное, но ничем не обоснованное, утверждение. В десктопе большинство софта будет работать без БД, будь то офисный пакет, смотрелки всяких файлов, файловый менеджер, архиваторы, VPN клиент... Имя им легион.
С уровнем промашка. Ответ на сообщение выше.
Плюсую. Для многих приложений уровня "утилита" использование БД избыточно. Чего ради авторы притягивают аргументы за уши неясно.
Про офисный пакет -- смотря что в него включать. В M365, например, помимо использования "родного" движка jet/ace в почтовом клиенте, есть/наполняются файлы sqlite. Вопрос для чего, и как такое вышло мне не даёт покоя.
Категорично как-то написано
На самом деле на платформе .NET есть три основных решения для данной ситуации (в реальности их будет и больше, скорее всего, но реально поддерживаемых, стабильных и проверенных только три).
Мне вот нравится библиотека linq2db
.NET 6 и провайдеры баз данных