Енто всё, конечно, очень прекрасно в целях саморекламы, но пробовали ли вы создать соответствующий(щие) issue с описанием всех найденных ошибок? Или хотя бы ссылкой на пост.
Было куда интереснее, если бы автор привел небольшое описание зачем вообще все это нужно. И для каких целей. Для тех людей, которые не в курсе терминов.
Если честно, я в принципе не вижу смысла в full-stack'e. Даже чистый backend я иногда разбиваю на 2 приложения, если логика их работы того подразумевает.
В чем заключается и чем плоха эта зловещая пропасть между беком и фронтом? Кто мешает программисту писать раздельный код, вместо фулстека, используя больше узконаправленных преимуществ каждого из подходов? Смотрите эти и другие холивары под этим комментом -_-
Короче, все эти статьи возникни на неправильном использовании дотнета, плюс они помогают и дальше его неправильно использовать. Неправильно это.
p.s. у меня как раз почти весь код использует IReadOnlyCollection, IReadOnlyList (если доподнительно нужен доступ по индексу), есть в том числе и IReadOnlyDictionary.
Этот ReadOnly-набор интерфейсов такой офигенный, и логическая потребность в нем настолько очевидна, что я искал в дотнете нечто подобное еще когда она даже не появилась (с 4.0 версии ввели).
Очень странно, что сейчас (уже вышел 4.7/7.2, есть куча ресурсов, русский SO, всякие митапы, и т.д.) все еще есть люди, которые так косячат, а что еще более странно, что на хабрe появляются статьи, которые вместо того, чтобы указать им верный путь, указывают этим людям как им продолжить писать неправильный код.
А маппинг названий ведь регистронезависимый? А как происходит маппинг свойств, тип которых — коллекция? А есть ли поддержка кастомного маппинга определенного типа?
Довольно бегло пролистал вашу статью, но не нашел толком информации по вложенным маппингам, а так же поддержки выражений для селекта из DB-провайдеров.
В автомаппере чаще всего использую именно что то в роде db.Users.GetAll<User>().ProjectTo<UserViewModel>()
и автомаппер автоматом подставляет нужное ваыражение, чтобы провайдер забрал только нужные поля из базы.
Я как то делал, помню, что инвок события OnPropertyChanged(string.Empty или null, не помню) вызывается сразу для всех свойств объекта, и не нужно вручную их все перебирать.
зависимости, если не тянутся сами по себе, можно попробовать впихнуть через костуру.
Четко, мб стоит выложить в paint.net плагины?
Енто всё, конечно, очень прекрасно в целях саморекламы, но пробовали ли вы создать соответствующий(щие) issue с описанием всех найденных ошибок? Или хотя бы ссылкой на пост.
Было куда интереснее, если бы автор привел небольшое описание зачем вообще все это нужно. И для каких целей. Для тех людей, которые не в курсе терминов.
Я бы добавил Task vs ValueTask обсуждение.
Если честно, я в принципе не вижу смысла в full-stack'e. Даже чистый backend я иногда разбиваю на 2 приложения, если логика их работы того подразумевает.
В чем заключается и чем плоха эта зловещая пропасть между беком и фронтом? Кто мешает программисту писать раздельный код, вместо фулстека, используя больше узконаправленных преимуществ каждого из подходов? Смотрите эти и другие холивары под этим комментом -_-
Не любой.
Например, агрегаторпо 2м элементами будет хранить O(1), а Reverse() будет хранить все O(N-1).
Короче, все эти статьи возникни на неправильном использовании дотнета, плюс они помогают и дальше его неправильно использовать. Неправильно это.
p.s. у меня как раз почти весь код использует IReadOnlyCollection, IReadOnlyList (если доподнительно нужен доступ по индексу), есть в том числе и IReadOnlyDictionary.
Этот ReadOnly-набор интерфейсов такой офигенный, и логическая потребность в нем настолько очевидна, что я искал в дотнете нечто подобное еще когда она даже не появилась (с 4.0 версии ввели).
Очень странно, что сейчас (уже вышел 4.7/7.2, есть куча ресурсов, русский SO, всякие митапы, и т.д.) все еще есть люди, которые так косячат, а что еще более странно, что на хабрe появляются статьи, которые вместо того, чтобы указать им верный путь, указывают этим людям как им продолжить писать неправильный код.
Я, если честно, что там откомментировал, что тут напишу: какой вообще смысл отдельно проверять IEnumerable на пустоту?
Вы читали статью? Ваш пример там указан как потребляющий O(N) памяти.
движение объектов в
FixedUpdate? а вы, сударь, ломатель стереотипов.Не нужен null? Тогда
struct.А как насчет этой новой фичи C# под названием класс?
А маппинг названий ведь регистронезависимый? А как происходит маппинг свойств, тип которых — коллекция? А есть ли поддержка кастомного маппинга определенного типа?
Довольно бегло пролистал вашу статью, но не нашел толком информации по вложенным маппингам, а так же поддержки выражений для селекта из DB-провайдеров.
В автомаппере чаще всего использую именно что то в роде
db.Users.GetAll<User>().ProjectTo<UserViewModel>()и автомаппер автоматом подставляет нужное ваыражение, чтобы провайдер забрал только нужные поля из базы.
Простенько, но со вкусом.
Я как то делал, помню, что инвок события OnPropertyChanged(string.Empty или null, не помню) вызывается сразу для всех свойств объекта, и не нужно вручную их все перебирать.
Используют
.Where(predicate).Count()вместо.Count(predicate)где то я читал, что первый вариант оптимальней
Очевидно, второй.
Какие-то детские задачки :S
Минус не мой, если что.