Комментарии 26
Помню были времена, когда в додо идеологически отказывались от ORM.
Кстати, а Price от Money всё ещё наследуется?
Может имело смысл рефакторить не код, а тесты? Ведь проблема была в in-memory db, которая у вас, как я понял, использовалась только для тестов
Это определенно помогло бы решить проблему.
Можно перейти на реальную базу данных, которая бы разворачивалась в каком-нибудь кубе каждый раз когда решение собирается на гитхабе и там бы мы прогоняли тесты.
Однако, нам нужно было быстрое решение. Не было возможности убедить всех, что нам нужно потратить N - количества времени на переделку тестов. С точки зрения non-IT это выглядит так: все работает отлично, ребята программисты почему то решили все сломать и теперь говорят, что им нужно сделать тесты по-другому, хотя раньше они отлично работали.
Красавцы, мигрируют с 3.1 на 6 за 20 минут. Я тут медленно ползу от 4.8 к 6 уже месяц как))
Что же их отличает? Отметаем в сторону наследование (иерархическую структуру первичных ключей в проекте мы пока не завели), остаётся то, что структуры не могут быть null, а вот классы ещё как могут.
А ещё класс передается по ссылке всегда (потому что ссылочный тип), а сутруктура — только если специально об этом попросить (указать ref). В результате те делегаты (например, типа Action<>), которые работают через побочный эффект — меняют свойства переданных в них экземплярах классов, сломаются, если заменить класс на структуру. А в .NET Core таких делегатов испольуется
Так что раз вы серьезно не нарвались — вам повезло.
Качественный код, особенно на уровне БД, обычно использует только read only типы.
Качественный код хорош в теории. А в реальной жизни приходится иметь дело с реальным кодом. И, насколько помню я тот же EF (EF 6 из Famework, к примеру), там сущности — они отнюдь не read only.
Но я писал немнго не про это. Вот, допустим, захотелось вам при инициализации создать и передать внутрь программы на ASP.NET некое строго типизированное составное значние (обозначим его тип как T). Штатный способ это сделать — Options pattern: при инициализации указывается делегат, которым инициализируется это значение, а в процессе работы из DI-контейнера достается один из сервисов-интерфейсов IOptions/IOptionsSnapshot/IOptionsMonitor, который при инициализации реализующего его объекта вызовет этот делегат, а потом через интерфейс можно получить значение. Так вот, делегат этот имеет, в простейшем случае тип Action, т.е. значение он не возвращает, и что-то полезное он может сделать, только вызвав побочный эффект.
Если у вас T — ссылочный тип (class) то все будет нормально, а если вы решите заменить его на struct — все сломается. И таких вот использований делегатов в .NET/ASP.NET не так уж и мало. Ну, допустим, для Options, на самом деле, ничего особо страшного не будет — код просто не скомпилится, т.к. у метода Configure есть ограничение where T:class, но ведь у самого типа делегата Action такого ограничения нет, и в него несложно передать после рефакторинга и струкутуру…
Зачем бизнесу продавать рефакторинг? Айти компании сами понимают необходимость, не-айти компании заплатят позже нефте- или банко- долларами полуторные или двойные рейты за уникальную возможность в дружном коллективе рефакторить легаси лапшу с зависимостями из 2010 года ))
это хорошо вы в монгу не залезли там вообще 7 вариаций. Причем обычный C# считается Legacy (3тий сверху)
Что означают "20 минут" в названии статьи?
Странно. Я по контексту догадался: рефакторинг и раскапывание внутренностей чего-нибудь типа EF - это явно не на 20 минут, и ведёт к проблемам с пищеварением.
Приключение на 20 минут: о чём надо помнить, когда затеваешь рефакторинг