Короче, все эти статьи возникни на неправильном использовании дотнета, плюс они помогают и дальше его неправильно использовать. Неправильно это.
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, не помню) вызывается сразу для всех свойств объекта, и не нужно вручную их все перебирать.
Использование проверок на Null, нужно стараться вообще исключить из кода. Не передавать ни в качестве аргумента в методы ни ожидать в параметрах конструктора. Если такое случается это повод задуматься об дизаине кода. Скорее всего проблема в нём.
Эта фраза полностью самодостаточно, все остальное после нее — лишнее.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет,
Но почему-то минусаторы не удосаживаются объяснить причину своего недовольства, видимо, любят тратить время на кучу проверок входных параметров у каждого метода своих классов.
Имхо, такой подход гораздо лучше. Разработчик ХОРОШЕЙ библиотеки не станет заморачиваться проверкой каждого угла на наличие null'ов. Его задача — правильно составить документацию, а в идеале — даже без нее, чтобы из названий классов и методов было ОЧЕВИДНО, возможен ли тут null или нет. А задача не пускать нулл должна быть на плечах пользователя библиотеки.
Короче, все эти статьи возникни на неправильном использовании дотнета, плюс они помогают и дальше его неправильно использовать. Неправильно это.
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
Минус не мой, если что.
Эта фраза полностью самодостаточно, все остальное после нее — лишнее.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет,
Но почему-то минусаторы не удосаживаются объяснить причину своего недовольства, видимо, любят тратить время на кучу проверок входных параметров у каждого метода своих классов.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет.
Имхо, такой подход гораздо лучше. Разработчик ХОРОШЕЙ библиотеки не станет заморачиваться проверкой каждого угла на наличие null'ов. Его задача — правильно составить документацию, а в идеале — даже без нее, чтобы из названий классов и методов было ОЧЕВИДНО, возможен ли тут null или нет. А задача не пускать нулл должна быть на плечах пользователя библиотеки.
Только если эта библиотека плнируется к использованию ну совсем новичками
Там вообще жесть :)
Динамичный метод не быстрее ли будет?