Здравый смысл есть, но все же идёт подмена понятий. Если замолкать вызовы то это юнит тест. Если вместо соков уже какая то реализация, то это не юнит. Есть ещё компонентные тесты, но тут сложно провести границу, где начнутся инновационные. Так что если вместо большого pgsql вы поставите SQLite, то юнит тестом это вы никак не можете назвать
Тут нет явного ответа. Согласен, что хорошо оформленный ридми даёт очень положительное впечатление. Но также важен и код. Если в публичном репозитории храниться spagetty код, который ещё и предлагается для ознакомления в качестве портфолио, то я такому кандидату отказываю
Если вы решаете "похвастаться" своими проектами на github, то делаете это аккуратно. Нужно быть полностью уверенным, что текущий код проекта на github соответствует вашим текущим скилам. Если это проекта двухлетней давности с довольно "плоским" решением, он никогда не добавить вас плюсов при рассмотрении вашей кандидатуры, а может даже быть и минусом. Конечно, автор наверно парирует своим же текстом, что если к вашему коду относятся без должного уважение, то такая компания вас не заслуживает. Но опять же. Если вы сейчас как мидл покажете ваш код юного джуна в мыслью что его должны обязательно учитывать, то не стоит потом сетовать что вас восприняли именно как джуна, а не мидла
Вот опять запихали репозиторий. Вот зачем? Ну когда возникает необходимость изменить ORM? Даже если такое потребуется, то все равно придется менять репозиторий, к гадалке не ходи. А так над EF, который и так реализует UoW+Repository ещё один «обвес». Опять же, все объяснения репозитория работают только с этими «лабораторными» приложениями (ToDo, People и т.п.). Когда появляются множественные связи, все рушиться, как карточный домик
Давно есть стандартная кросплатформеная либа для работы с изображениями на .Net Core devblogs.microsoft.com/dotnet/net-core-image-processing
Да, тот же ImageSharp обладает готовыми методами и хэлперами. Но в любом случае это готовое решение. В своем проекте я именно его использовал для резайза. Более чем доволен результатом
Что-то подобное уже читал, кажется на medium.
Вот как это часто бывает, все на пример Hello World. Все вокруг похлопали и забыли, потому что нет описания реального применения.
Неудобство флага fake в том, что классы сервисов становятся слишком большими и содержат логику к ним не относящуюся. Более правильно сделать абстрактный класс сервиса и два наследника: реализация сервиса и фейковый. В случае фейк-режима, фабрика будет инжектировать фейк-сервис. Но и это порождает много дополнительного кода, ведь для каждого сервиса, работающего в фейк-режиме, необходимо иметь фабрику для инжектирования, а также базовый абстрактный класс. Поэтому в таком случае, лучше всего использовать HttpInterceptor, выдающий определенные ответы. Тогда и код фейковых запросов будет строго изолирован, и сервисы не потребуют дополнительного кода. Более того, сервисы даже знать не будут, что работают с фейковыми данными
Ещё один паникер. Один раз раскупили к некоторых магазинах макароны, так форумы тут же взорвались.
От себя: да, народу мало, многие в масках или их «заменителях». Но никаких пустых полок в магазинах нет. Разве что много раскуплено в онлайн-магазинах. Причины: кто-то боится выходить на улицу, кто без масок после новостей о том, что не будут пускать без них просто сидит дома, кто-то просто «закупился по максимуму».
Согласен с автором на счет тестирования БД. Да, это будут уже совсем не unit-тесты, а интеграционные. Но, как правильно было замечено, попытка замокать приводит к копипасту кода EF. Кстати, нельзя просто так замокать DbContext или DbSet. Отсюда вытекают фразы «так есть же шаблон UnitOfWork + Repository». Опять начинаются «танцы с бубном», чтобы обернуть EF в шаблон репозиторий, в то время как сам EF уже реализует UnitOfWork+Repo.
Второе. Когда ж, закончиться этот ужас с #if DEBUG. Ну специально для этого в .Net Core при работе с файлами конфигураций добавили поддержка имени окружения. Не зря же пустом проекте можно найти appsettings.json и appsettings.development.json
Почему не рассматривается вариант с проектом интеграционных тестов в Core? В своей практике я всегда его использовал для работы unit-тестов, связанных с БД. Нужна минимальная «обвязка». К тому же, в некоторых случаях необходимо работать с in-memory database. В случае статического метода, класс контекста начинает «обрастать» новыми метода, в зависимости от сценариев использования, что никак не добавляет читабельности коду. Даже class helpers проблему не решат, а только спрячут ее
Вот как раз 0 или 1.. Их заголовки это тоже данные, не имеющие отношение к данным. Но не будем спорить в этом русле, потому как и ваш вариант также укладывается в MVC. Я говорю немного о другом. Если заголовки enum относить к представлению, то получается, что одни и те же данные и бизнес платила для них будут находится на нескольких уровнях. И это главная проблема. Да, тут можно поспорить, "что есть представление", не отрицаю, тут ваши аргументы весомы. Но для чего обычно используется enum (точнее когда я его использую). Когда необходимо описать набор значений, от которых может зависеть бизнес-логика, когда это крайне неудобно представлять в виде отдельной таблицы в БД. Например, при описании набора состояний, особенной когда по условиям задачи, варианты состояний не меняются. Если это реализовать в виде таблицы, то в коде будет неявная свять, в виде "если Id=0, то вызываем какую то функцию". Поэтому и удобнее использовать enum. Это позволяет определить набор состояний, которые можно хранить в базе и которые однозначно определяются в коде. Но это пять же мое мнение.
Не совсем соглашусь с вами. То, что 0 соответствует строке «Any», а 1 — «Open» это никак не слой представления, это данные. 0 и 1 это идентификаторы. Строки — значения, им соответствующие.
Но наша идея интересная и имеет место быть.
Enum используется в проекте «исторически» и задача по стоит поддерживать чтение из существующей базы.
В конкретно взятом случае — да. Но если это веб-сервис, или вам нужно получить список сущностей с фильтрацией и сортировкой, то маппинг плохая идея. Тут нужно проекцией пользоваться
В статье как раз есть такой хелпер EnumHelper.GetShortname
Но идея то не в этом, а в том, как эту операцию "отправить" в sql-запрос, чтобы не вытягивать из базы все записи, а потом маппить из поля
Согласен. Но это уже будет не будет «не то». В таком случае, используя Automapper, в запрос будут добавлены `JOIN`.
Я говорил о том, что не получиться создать индекс для проекции, создаваемой «на лету». Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Если вы уже получили корректный IQueryable, т.е. когда как минимум можно получить данные через ToArray/ToList, значит запрос корректно транслируется в sql-запрос.
В данном случае, нужно помнить что тип данных результирующей колонки будет STRING. Поэтому при применении сортировки и фильтрации к этому полю, операции будут применяться к строковому результату, а не к исходному числовому enum.
Здравый смысл есть, но все же идёт подмена понятий. Если замолкать вызовы то это юнит тест. Если вместо соков уже какая то реализация, то это не юнит. Есть ещё компонентные тесты, но тут сложно провести границу, где начнутся инновационные. Так что если вместо большого pgsql вы поставите SQLite, то юнит тестом это вы никак не можете назвать
Тут нет явного ответа. Согласен, что хорошо оформленный ридми даёт очень положительное впечатление. Но также важен и код. Если в публичном репозитории храниться spagetty код, который ещё и предлагается для ознакомления в качестве портфолио, то я такому кандидату отказываю
Если вы решаете "похвастаться" своими проектами на github, то делаете это аккуратно. Нужно быть полностью уверенным, что текущий код проекта на github соответствует вашим текущим скилам. Если это проекта двухлетней давности с довольно "плоским" решением, он никогда не добавить вас плюсов при рассмотрении вашей кандидатуры, а может даже быть и минусом. Конечно, автор наверно парирует своим же текстом, что если к вашему коду относятся без должного уважение, то такая компания вас не заслуживает. Но опять же. Если вы сейчас как мидл покажете ваш код юного джуна в мыслью что его должны обязательно учитывать, то не стоит потом сетовать что вас восприняли именно как джуна, а не мидла
devblogs.microsoft.com/dotnet/net-core-image-processing
Да, тот же ImageSharp обладает готовыми методами и хэлперами. Но в любом случае это готовое решение. В своем проекте я именно его использовал для резайза. Более чем доволен результатом
Вот как это часто бывает, все на пример Hello World. Все вокруг похлопали и забыли, потому что нет описания реального применения.
От себя: да, народу мало, многие в масках или их «заменителях». Но никаких пустых полок в магазинах нет. Разве что много раскуплено в онлайн-магазинах. Причины: кто-то боится выходить на улицу, кто без масок после новостей о том, что не будут пускать без них просто сидит дома, кто-то просто «закупился по максимуму».
Вот и будет у вас окружение
Второе. Когда ж, закончиться этот ужас с #if DEBUG. Ну специально для этого в .Net Core при работе с файлами конфигураций добавили поддержка имени окружения. Не зря же пустом проекте можно найти appsettings.json и appsettings.development.json
Почему не рассматривается вариант с проектом интеграционных тестов в Core? В своей практике я всегда его использовал для работы unit-тестов, связанных с БД. Нужна минимальная «обвязка». К тому же, в некоторых случаях необходимо работать с in-memory database. В случае статического метода, класс контекста начинает «обрастать» новыми метода, в зависимости от сценариев использования, что никак не добавляет читабельности коду. Даже class helpers проблему не решат, а только спрячут ее
Вот как раз 0 или 1.. Их заголовки это тоже данные, не имеющие отношение к данным. Но не будем спорить в этом русле, потому как и ваш вариант также укладывается в MVC. Я говорю немного о другом. Если заголовки enum относить к представлению, то получается, что одни и те же данные и бизнес платила для них будут находится на нескольких уровнях. И это главная проблема. Да, тут можно поспорить, "что есть представление", не отрицаю, тут ваши аргументы весомы. Но для чего обычно используется enum (точнее когда я его использую). Когда необходимо описать набор значений, от которых может зависеть бизнес-логика, когда это крайне неудобно представлять в виде отдельной таблицы в БД. Например, при описании набора состояний, особенной когда по условиям задачи, варианты состояний не меняются. Если это реализовать в виде таблицы, то в коде будет неявная свять, в виде "если Id=0, то вызываем какую то функцию". Поэтому и удобнее использовать enum. Это позволяет определить набор состояний, которые можно хранить в базе и которые однозначно определяются в коде. Но это пять же мое мнение.
Но наша идея интересная и имеет место быть.
Enum используется в проекте «исторически» и задача по стоит поддерживать чтение из существующей базы.
В конкретно взятом случае — да. Но если это веб-сервис, или вам нужно получить список сущностей с фильтрацией и сортировкой, то маппинг плохая идея. Тут нужно проекцией пользоваться
В статье как раз есть такой хелпер
EnumHelper.GetShortnameНо идея то не в этом, а в том, как эту операцию "отправить" в sql-запрос, чтобы не вытягивать из базы все записи, а потом маппить из поля
В любом случае, мы явно отдалились от изначального вопроса.
Я говорил о том, что не получиться создать индекс для проекции, создаваемой «на лету». Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Индексация над проекцией в принципе невозможна.
Например, есть таблица USERS с ID, NAME, SURNAME.
Какой тут индекс?
Если вы уже получили корректный
IQueryable, т.е. когда как минимум можно получить данные черезToArray/ToList, значит запрос корректно транслируется в sql-запрос.В данном случае, нужно помнить что тип данных результирующей колонки будет
STRING. Поэтому при применении сортировки и фильтрации к этому полю, операции будут применяться к строковому результату, а не к исходному числовому enum.