📚7 лучших библиотек C# для парсинга веб-страниц в 2023 году

• Существуют различные библиотеки веб-скрейпинга на C# для извлечения данных, в том числе для таких целей, как отслеживание цен, генерация потенциальных клиентов, мониторинг настроений, агрегация финансовых данных и так далее.

Так же, существуют разные показатели, которые следует учитывать при выборе лучшей библиотеки для парсинга, и в этой статье мы обсудим 7 лучших библиотек для парсинга на C# для использования в 2023 году. Кроме того, мы увидим примеры, которые помогут вам понять, как эти фреймворки работают.

1. ZenRows API — лучшая библиотека веб-парсинга данных на C# в этом списке. Это API, который обрабатывает обход ботов от вращающихся прокси и безголовых браузеров до CAPTCHA.

2. Puppeteer Sharp — это библиотека для парсинга на C#, которая сканирует веб-страницу с помощью браузера без заголовка.

3. Веб-драйвер Selenium — один из наиболее часто используемых инструментов для парсинга больших объемов данных, таких как фотографии, ссылки и текст.

4. HTML Agility Pack - является наиболее загружаемой библиотекой парсинга C# DOM благодаря своей способности парсить веб-страницы напрямую или через браузер.

5. Scrapy Sharp - это библиотека веб-парсинга на C# с открытым исходным кодом, которая объединяет расширение HTMLAgilityPack с веб-клиентом, который может эмулировать веб-браузер, например jQuery.

6. Iron Web Scraper — это библиотека веб-скрейпинга .Net Core C#, исользуемая для извлечения и анализа данных из интернет-источников. Она способна контролировать разрешенные и запрещенные объекты, сайты, медиа и другие элементы.

7. HttpClient — это библиотека парсинга HTML на C#, которая предоставляет асинхронные функции для извлечения только необработанного содержимого HTML из целевого URL-адреса. Однако для извлечения нужных данных вам по-прежнему необходимо использовать инструмент синтаксического анализа HTML.

#полезное #tips

Шёл 2023-й год, а некоторые C# разработчики, даже "ведущие", продолжают штамповать обобщённые репозитории...

Мда...🤡

https://habr.com/ru/companies/itq_group/articles/747566/

Об этом не писал только ленивый…

Итак, почему обобщённый репозиторий - это антипаттерн.

Прежде всего, давайте вспомним, что из себя представляет паттерн репозиторий, особенно популярный в DDD.

Согласно Дяде Бобу, репозиторий посредничает между доменом и слоем представления данных, находясь в роли in-memory коллекции доменных объектов.

Проще говоря, это фасад для доступа к данным, который оборачивает конкретный источник данных: ORM, сервис, СУБД, файловая система, Active Directory и т.д.

Так вот, начну с неочевидного.

Если вы используете ORM, например, Entity Framework или NHibernate, то следует помнить, что эти библиотеки сами по себе предоставляют реализации не только обобщённых репозиториев, но и единиц работы Unit Of Work.

В случае EF DbContext является UOW, а DbSet<T> это обобщённый репозиторий.
В случае NHibernate оба паттерна инкапсулированы внутри ISession.

Соответственно, создание новой обёртки поверх существующей аналогично переизобретению колеса, которое ещё и будет квадратным.

В отрыве от ORM, конечно обобщённые репозитории, в силу своей "обобщённости", превращаются в DAL код, намертво впаенный в алгоритмы бизнес-логики.

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

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

А домен не является обобщённым. Не каждая сущность может быть добавлена/удалена или отредактирована единым образом, не у каждой сущности будет репозиторий вовсе.

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

С другой стороны, репозиторий определяет операции, которые хранилище данных можнт осуществлять над доменными объектами.

А обобщённый вариант не предоставляет осмысленного контракта.
Просто сравните две сигнатуры ниже:

// вообще не понятно, что происходит
IEnumerable<T> Find(object param);

// более читабельный код, который чётко определяет
// отношение между хранилищем данных и доменным объектом
IEnumerable<Customer> FindCustomerByName(string name);

Все эти аргументы говорят в пользу того, что создание обобщённых репозиториев - плохо в любом году.

#полезное #tips

AutoFixture killer feature

Разбираясь в библиотеке AutoFixture пришёл к выводу, что её главное назначение это минимизация Arrange этапа в тесте.

За счёт чего это достигается? Специальные атрибуты для интеграций с фреймворками xUnit и NUnit предоставляют всю необходимую магию.

Например, атрибут AutoData.
Допустим, у нас есть некоторая корзина, которую надо протестировать на добавление позиций.
Как бы выглядел тест без AutoFixture?

[Fact]
public void Cart_NotNullItem_NotEmpty()
{
    var item = new Item();
    var sut = new Cart();

    sut.AddItem(item);

    Assert.NotEmpty(sut.Items);
}

А после применения атрибута?

[Theory, AutoData]
public void Cart_NotNullItem_NotEmpty(Item item, [Frozen] Cart sut)
{
    sut.AddItem(item);

    Assert.NotEmpty(sut.Items);
}

Теперь весь Arrange лёг на плечи библиотеки и больше не надо волноваться по поводу template кода с инстанциированием!
Ну а расширять поведение под нужды валидаций или каких-то moq'ирований естественно можно, но об этом в другой раз.

Ставьте огонёчки, если хотели бы узнать о том, что такое Arrange и подход AAA в тестировании.

#полезное #tips

Как лучше регистрировать коллекцию зависимостей?

Представим, что вам нужно внедрить коллекцию из сервисов типа IMyService. Тогда вы ожидаете её вот так:

class MyOtherService : IMyOtherService
{
    public MyOtherService(IEnumerable<IMyService> myServices)
    {
        //...
    }
}

Что приходит на ум?

▪️Создать свою кастомную коллекцию, и зарегистрировать её.

▪️Буквально зарегистрировать объект списка или массива с набором нужных зависимостей

Однако можно поступить гораздо проще и просто регистрировать зависимости как обычно. Например:

services.AddScoped<IMyService, MyService>();

DI контейнер всё поймёт и даже если будет зарегистрирована всего одна реализация, она будет представлена в коллекции.

#полезное #tips