Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

ладно, я, наверно, затупил, ведь способ есть - просто создать интернал конструктор , в котором задавать значения полей из обязательных параметров. Просто хотелось бы через "фичу" с required то же самое делать (чтобы код конструктора был меньше), но, видимо, никак.

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

так в том и дело, что не понятно, как сделать, чтобы код внутренней сборки , создавая экземпляр, обязательно задавал проперти (не оставлял незаданными нуллами), а внешний код из другой сборки не мог создавать экземплляры, но мог читать проперти.

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

> я правильно понял? желание скрыть код?

нет конечно. просто структурирование областей видимости внутри кода: обязать классы из той же сборки обязательно задавать проперти при создании экземпляра и запретить другим классам с внешних сборок создавать экземпляры. Вариант сделать класс internal не работает, т.к .public поля класса в этом случае вовсе не public , а internal , и внешний код их не может видеть.

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

А то и проблема - когда я делаю так, я не могу задать required для модификаторов set или init у проперти , чтобы обязать классы из той же сборки, которые создают экземпляры, обязательно устанавливать это проперти.

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

>Представь ситуацию, что кто-то во внешней сборке создает твой класс и ему обязательно нужно будет инициализировать это поле - он не сможет, т.к. internal set.

у меня как раз требование, чтобы внешние сборки не создавали экзезмпляры, а их могла создавать только та же сборка (поэтому конструктор internal ).

>1. Объяви класс как internal
да, такой вариант не выдает ошибки, но я не понял - разве internal классы видны из других сборок (написал UPDATE по этому поводу)?

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

>Что это значит? Допустим, у вас класс public class QQQ, а внутри него есть обязательное поле Dddd. Допустим, вы хотите создать объект этого типа из другого проекта. Как вы это сделаете? Ответ - НИКАК.

мой вопрос потому и возник, что мне нужно запретить создавать экземпляры QQQ из другого проекта, а позволять создавать экземпляры QQQ только из того же проекта.

Почему required проперти не могут иметь более ограничиващий модификатор set\init, чем модиикатор класса, их содержащего?

>ps может internal или protected internal? в смысле для класса..

да, так нет ошибок. Но я понять не могу - а разве internal класс будет виден за пределами сборки ? (написал по этому поводу UPDATE)

Почему в телеграме картинки отображаются по-разному?

IvanU7n, нет, дело, скорее, не только в формате. Т к у меня скрины экрана идут то мелким превью, то крупным. Потестил и заметил, что если на Андроиде при загрузке файла выбрать "галерея" и оттуда картинку, то вставляется крупный план. Если выбрать "файл" и вставлять оттуда, то мелкие превью. Вот какой идиот это придумал? И почему эта шляпа до сих пор не переделана теми же идиотами, неужели я первый, кто жалуется?
Может, конечно, скрины, которые я загружаю через "файл" , можно грузить через "галерею", но вроде нет,т к скорее всего они там не видны, поэтому приходится грузить через "файл"

Почему в телеграме картинки отображаются по-разному?

Ок, заскринил.
https://ibb.co/fHfDr4B
В 12:34 загружена фотка, она сжалась до мелкого квадрата и справа от нее название файла.

В 17:08 загружена фотка, которая не сжалась и показывается крупным планом без обрезки и без информации о названии.

И главное, что если открыть первую фотку и начать проматывать, то вторая не покажется. А если открыть вторую и начать проматывать, то первая не покажется.

Неужели никто вообще никогда не обращал внимание на это, что телеграм хз по какому принципу дифференцирует загрузки фоток либо в маленькую, либо в большую? Да ещё не позволяет прокрутку между ними. Это похоже на баг, но был бы баг, то это исправили бы уже давно. Но эта лажа длится уже минимум кучу месяцев, а скорее всего кучу лет.

Правда ли что рынок веб разработки "перегрет"?

Перегрет в плане зарплат? Скорее всего. Перегрет в плане количества разработчиков? Вряд ли. Пока спроса очень много.

Что? Это как? Типа программистов очень мало и нужно больше, но зарплаты мы будем понижать (чтобы их стало еще меньше? чтобы к нам ни один программист не пошел, а пошел к конкурентам или с сферу, где зп растет, а не падает?)?

В чем польза шардирования БД при наличии индексов?

На прошлой работе как раз были проблемы со скоростью загрузки данных с большой базы и таймауты, при этом были созданы все индексы, поэтому одним из вариантов ускорения загрузки с бд как раз рассматривалось шардирование. Не знаю, в итоге реализовали его или нет, но если даже реализовали, то оно и не должно было ничем помочь?

Непонятное объяснение нового пула потоков в .NET - кто-нибудь может разъяснить?

GorgeousPuree нет , не разобрался. Если сами разберетесь, то чирканите объяснение в этот тред тоже.

Как работают проперти со значимыми типами - почему так?

Значение копии то меняется, но затем оно заносится обратно.

Да, так , видимо, и есть.
a.Mutable.X++ тоже работает, если Mutable не проперти, а поле. Если сделать его проперти, а не поле, то перестает работать, т.к. происходит ошибка Cannot modify the return value of 'A.Mutable' because it is not a variable

Как раз из-за этого я и задал вопррс, т.к. сначала не понял, почему Mutable как проперти не работает, а Х как проперти работает. Сейчас я все понял. Если Mutable поле, а X проперти, то у оригинала Mutable возвращается копия X, копия Х инкрементится и присваивается снова в X, т.е. у оригинала Mutable увеличивается X. А если Mutable это проперти, то возвращается копия Mutable, у копии Mutable возвращается копия X, копия Х инкрементится и присваивается снова в X, т.е. у КОПИИ Mutable увеличивается X. А т.к. копия Mutable не сохранена ни в какую пересенную, то и возникает эта ошибка о бессмысленном изменении поля копии.

Невосстановимое удаление данных - как?

И странно, конечно, что там есть какая-то "остаточная намагниченность", а не просто 0 и 1. Выходит, что вместо 0 там может быть 0,5, и как тогда этот бит 0,5 при чтении файла прочитаться должен - как 0 или как 1? В общем, ладно, я в железе и электронике все-равно не разбираюсь. Но интересно, эта "остаточная намагниченность" не только в жестких дисках, но и в ssd возможна? Технологии же разные. Нужно ли ssd тоже перезаписывать максимальным кол-вом проходов, или достаточно 1 прохода?

Невосстановимое удаление данных - как?

2. При форматировании диска - удаляется информация таблицы размещения файлов, содержимое кластеров остаётся почти без изменений. Так что на диске лежит куча анонимных кусков файлов.

Это при каком форматировании - быстром или небыстром?
И тогда непонятно, если при небыстром форматировании данные остаются, то почему recuva не может восстановить файлы, это же ее прямая обязанность. И еще более странно то, что после "зачистки следов" с помощью revo uninstaller recuva смогла увидеть содержимое файлов (а после небыстрого форматирования не смогла).

ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?

Теперь понял. Изначально я так и хотел сделать, но меня остановило то, что я все хотел регистрировать внутри IoC, но при такой схеме внутри IoC можно регистрировать dataLayer и Business, а webApi нужно регистрировать в webApi. В итоге я инвертировал зависимость между webApi и IoC, и у меня все теперь регистрируется в IoC.

ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?

Станислав Силин, Картинку понял, но не понял, как webApi регистрирует себя в IoC, если webApi - стартующий проект и он не знает про Ioc?
У меня схема такая вышла:

ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?

Станислав Силин,

Вспомните как вы подключаете EF, это проиходит приблизительно так:

не, я не так делаю. я так понял, это какой-то встроенный в asp.net core ioc ? Я юзаю .net framework и ioc castle windsor.

т.е. регистрация компонетов уже разнесена по разным проект.

Т.е., я так понял, в вашей структуре есть IoC-проект, а все остальные проекты (webApi, DataAccess, BusinessLogic, Domain) референсятся на IoC-проект, и каждый проект сам себя регистрирует в IoC? С webApi понятно - он запускающийся, он может себя зарегать. Не понятно, как себя регистрируют остальные сервисы, т.к. если они регистрируют себя сами, то webApi должен напрямую вызвать их методы регистрации, но webApi ничего не должен знать об остальных сервисах.

Я у себя сделал обратную картину - есть запускающийся Ioc , он знает обо всех сервисах, сервисы не знают друг о друге, Ioc сам внутри себя регистрирует все сервисы

ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?

Получается, что регистрация компонентов для контейнера будет разнесена по разным проектам. Не лучше ли все в одном? И референсы на IoC-библиотеку будут только в одном проекте, а не в многих.

ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?

Я не могу вынести IoC в отдельный проект, т.к. мой IoC должен зарегистрировать контроллеры, т.к. контроллеры приходится создавать не автоматически (как по умолчанию), а вручную через IoC.Resolve, потому что контроллеры принимают в конструкторе зависимости, а автоматическое создание контроллеров не работает с параметризованными конструкторами. Из-за этого, если вынести IoC в отдельный проект, а контроллеры оставить в стартующем проекте (webApi), то получается, что стартующий проект (webApi) должен ссылаться на IoC для инициализации IoC, а IoC должен ссылаться на стартующий проект (webApi) для того, чтобы получить из него контроллер для регистрации. Получается круговая зависимость, которая невозможна. Интересно, а как вы это у себя разруливали?

Я сейчас вынес контроллеры в отдельный проект, а IoC оставил в стартующем проекте, все работает, но, конечно, в стартующем проекте остаются референсы на библиотеки, которые там больше не нужны, и их нужно перенести в проект контроллеров, а этой геморойно. Но меня больше беспокоит вопрос, что если такую мою схему разбивки на проекты кто-нибудь из опытных разрабов увидит, то меня сразу за лузера посчитают, или, наоборот, они даже оценят схему, т.к. схема имеет право на жизнь (просто я в жизни ни разу такой разбивки не видел, когда контроллеры отдельно от стартующего проекта выносят)?