Впрягусь: юзинги без скобок нужны, когда их много, чтобы код не сдвигался слишком сильно вправо. Ещё часто ресурс создаётся в начале и уничтожается в конце функции. Тут юзинги без скобок тоже подходят.
Я использовал подобный подход и по итогу запросы из репозитария расползаются по всей программе и реализованы немного по разному. За этим нужно следить.
В итоге использую всевозможные построили запросов только внутри репозитария. Это внутреннее дело репы, как оно там всё хранится и как строить запросы. Но у меня своя специфика в виде даппера.
Чтобы справиться с комбинаторным взрывом использую концепцию фильтров, когда null обозначает отсутствие фильтра. Например: GetEmployees(Sex? sexFilter = null, int? minAgeFilter = null, ...). При вызове явно указываю названия использованных фильтров, чтобы не было GetEmployees(false, 24).
Ситуации, когда нужно много и хитро фильтровать у меня возникают редко, обычно делаю выборки по включению значений или диапазону. Т.е. нет необходимости как-то хитро, а главное разнообразно делать выборки в прикладном коде, хватает небольшого количества методов репозитария.
У меня довольно мало случаев, когда маппинг 1 к 1: либо названия меняются, либо нужно преобразование с подтягиванием каких-то данных делать. Чисто теоретически, сложилось ощущение, то автомаппинг настраивать надо и это как-то не сильно выгоднее, чем присвоить поле руками.
В каких реальных кейсах помогает автомапинг? есть примеры кода?
Мне не чтобы докопаться, мне чтобы работу свою облегчить.
Я люблю использовать обёртки структуры над элементарными типам. Например, если в бд есть число наличия товара и 0 - обозначает "под заказ", то обёртка "доступное количество" будет содержать метод для проверки под заказ ли этот товар, чтобы по коду не расползалисьavailableQuantity == 0. Ну или ноль в специальной константе находится, но сути это не меняет. Т.е. знание о том, что значит 0 находится ровно в одном месте и это хорошо.
На самое интересное, что структура над интом в результате компиляции исчезает из ассемблерного кода: по функциям путешествует обычный инт, а функции инлайнятся. Прямо zero cost abstraction.
Вместо перемапливания создаём класс или структуру суть которой сводится к public int Id => person.Id;. Я так даже делал когда генерировал отчёт и обёртка уходила в генератор экселины.
А бесплатность была про то, что код маппинга всё равно писать и без разницы будет это обёртка или копирование в отдельный объект.
Я же главную проблему с обёртками вижу в связи обёртки с оборачиваемым типом. В ситуации, когда зависимая библиотека выставляет контракт и ничего не знает про наши типы, обёртку в неё можно будет передать только как наследника интерфейса. В дикой природе такое не встречается и обычно либы принимают какие-то свои ДТОхи.
Я простой разраб и статья явно не для меня написано, но всё же спрошу: как лично я могу использовать лоу код платформы в своей работе? В начале работы не увидел ничего про начало работы (:
Может быть, автоматизация какой-то рутины? Или я кажу заказчику в какой-то момент: не надо кодить, мы сделаем это в 10 раз быстрее с помощью хххх?
Как человек написатель/читатель ПРов вижу такое противоречие:
Программист хочет рефакторить вместе с задачей, потому что он видит актуальные проблемы кода, ему не удобно и т.п.
Ревьюер хочет смотреть рефакторинги отдельно от задачи, чтобы уменьшить сложность и повысить качество ревью.
Возможное решение: пока делаешь основную задачу, кидаешь ПРы с микрофакторингами в отдельных ветках. Эти ветки можно подтягивать в свою ветку как до и так после прохождения ревью.
А как быть, если рефакторинг требуется для решения задачи?
Сначала сделать ветку с рефакторингом и пока он апрувится от этой же ветки делать фичу?
Просто вижу проблемы с асинхронностью: обычно необходимость рефакторинга осознается, когда работаешь с кодом в рамках какой-то задачи. Как тут встроить рефакторинг в процесс, чтобы не тормозить основную задачу?
Чтобы дёшево поиграться можно взять видеокарту в облаке.
Сервер обойдётся где-то 50-100р в час в зависимости от видеокарты.
Чтобы не платить по 20к в месяц, после использования сервер нужно гасить. А перед использование создавать. Главное сохранить жёсткий диск. За него придётся платить где-то 100-1000р в месяц в зависимости от размера и типа.
А какие шаблоны лучше во всех отношениях чем enum?
Впрягусь: юзинги без скобок нужны, когда их много, чтобы код не сдвигался слишком сильно вправо. Ещё часто ресурс создаётся в начале и уничтожается в конце функции. Тут юзинги без скобок тоже подходят.
var нужен для анонимных типов. А анонимные типы нужны были Linq, а без linq шарп не шапр.
Запуск без Main, глобальные юзинги и обобщённая математика нужны для ML. Догоним и перегоним питон типа. Мне ML никуда не упёрся, но и не мешает.
А свич кейсы лично мне нравятся, стало удобнее.
У нас в компании нет менеджеров, но я полностью согласен, что
Я использовал подобный подход и по итогу запросы из репозитария расползаются по всей программе и реализованы
немного по разному. За этим нужно следить.В итоге использую всевозможные построили запросов только внутри репозитария. Это внутреннее дело репы, как оно там всё хранится и как строить запросы. Но у меня своя специфика в виде даппера.
Чтобы справиться с комбинаторным взрывом использую концепцию фильтров, когда null обозначает отсутствие фильтра. Например:
GetEmployees(Sex? sexFilter = null, int? minAgeFilter = null, ...). При вызове явно указываю названия использованных фильтров, чтобы не былоGetEmployees(false, 24).Ситуации, когда нужно много и хитро фильтровать у меня возникают редко, обычно делаю выборки по включению значений или диапазону. Т.е. нет необходимости как-то хитро, а главное разнообразно делать выборки в прикладном коде, хватает небольшого количества методов репозитария.
А как понять что она выше по приоритету? В предложенной схеме то что справа выше всего, не зависимо от приоритета карточки, как я понял.
Вот пример где DTO и геттер - не sealed. Один фиг не получится поле заоверрайдить, если оно не виртуальное.
Если не прав, жду ссылку на код.
У меня довольно мало случаев, когда маппинг 1 к 1: либо названия меняются, либо нужно преобразование с подтягиванием каких-то данных делать. Чисто теоретически, сложилось ощущение, то автомаппинг настраивать надо и это как-то не сильно выгоднее, чем присвоить поле руками.
В каких реальных кейсах помогает автомапинг? есть примеры кода?
Мне не чтобы докопаться, мне чтобы работу свою облегчить.
А какие есть варианты лучше, именно с точки зрения поддержки?
Кажись нет: не получится оверрайдить не виртуальные функции и после каста к исходной дто, значения будут читаться из исходных полей.
Я люблю использовать обёртки структуры над элементарными типам. Например, если в бд есть число наличия товара и 0 - обозначает "под заказ", то обёртка "доступное количество" будет содержать метод для проверки под заказ ли этот товар, чтобы по коду не расползались
availableQuantity == 0.Ну или ноль в специальной константе находится, но сути это не меняет. Т.е. знание о том, что значит 0 находится ровно в одном месте и это хорошо.На самое интересное, что структура над интом в результате компиляции исчезает из ассемблерного кода: по функциям путешествует обычный инт, а функции инлайнятся. Прямо zero cost abstraction.
Вместо перемапливания создаём класс или структуру суть которой сводится к
public int Id => person.Id;. Я так даже делал когда генерировал отчёт и обёртка уходила в генератор экселины.А бесплатность была про то, что код маппинга всё равно писать и без разницы будет это обёртка или копирование в отдельный объект.
Я же главную проблему с обёртками вижу в связи обёртки с оборачиваемым типом. В ситуации, когда зависимая библиотека выставляет контракт и ничего не знает про наши типы, обёртку в неё можно будет передать только как наследника интерфейса. В дикой природе такое не встречается и обычно либы принимают какие-то свои ДТОхи.
Спасибо, пользы больше чем от статьи
Я простой разраб и статья явно не для меня написано, но всё же спрошу: как лично я могу использовать лоу код платформы в своей работе? В начале работы не увидел ничего про начало работы (:
Может быть, автоматизация какой-то рутины?
Или я кажу заказчику в какой-то момент: не надо кодить, мы сделаем это в 10 раз быстрее с помощью хххх?
Как человек написатель/читатель ПРов вижу такое противоречие:
Программист хочет рефакторить вместе с задачей, потому что он видит актуальные проблемы кода, ему не удобно и т.п.
Ревьюер хочет смотреть рефакторинги отдельно от задачи, чтобы уменьшить сложность и повысить качество ревью.
Возможное решение: пока делаешь основную задачу, кидаешь ПРы с микрофакторингами в отдельных ветках. Эти ветки можно подтягивать в свою ветку как до и так после прохождения ревью.
На это нужна политическая воля
А как быть, если рефакторинг требуется для решения задачи?
Сначала сделать ветку с рефакторингом и пока он апрувится от этой же ветки делать фичу?
Просто вижу проблемы с асинхронностью: обычно необходимость рефакторинга осознается, когда работаешь с кодом в рамках какой-то задачи. Как тут встроить рефакторинг в процесс, чтобы не тормозить основную задачу?
Если я правильно понял позиционирование фокуса, он как раз таки должен выдавать картинку на уровне mj по простым промтам.
Чтобы дёшево поиграться можно взять видеокарту в облаке.
Сервер обойдётся где-то 50-100р в час в зависимости от видеокарты.
Чтобы не платить по 20к в месяц, после использования сервер нужно гасить. А перед использование создавать. Главное сохранить жёсткий диск. За него придётся платить где-то 100-1000р в месяц в зависимости от размера и типа.
Понял
Просто обычно к подобным статьям прикладывают репу с кодом и у меня возникли неоправдавшиеся ожидания
Вообще я хотел порефачить код, т.к. в коде много технических деталей и, кажется, можно повысить уровень абстракции, чтобы алгоритм был более явным.