А можно немножко расшифровать предлагаемый подход.
Вот допустим у нас есть класс AuthorizationService который где то там использует метод GetUser.
Этот метод GetUser должен быть на интерфейсе, допустим, IUserRepository у которого две реализвации EntityFrameWorkUserRepository и XmlFileUserRepository.
С точки зрения существующего C# какие монады
Какие монады или Exception должен декларировать IUserReporsitory?
Как примерно должен выглядеть код обработки ошибок? В AuthorizationService и репозиориях? — т.е. как транслировать ошибки более высокого уровня в более низкого уровня.
При возникновении ошибок как будет выглядеть лог? (В случае Exception мы получаем stack trace).
Еще интересно было бы узнать, как это предлагается сделать в языке мечты автора.
Эта система называется в Windows "Microsoft Store". Достаточно перейти по ссылке и там есть все. Если у кого-то не получается этим воспользоваться то самим терминалом он не сможет пользоваться просто потому, что это техническая программа.
LINQ is monad. It is very carefully designed by Erik Meijer so that it is monad.
Eric Lippert also mentioned:
The LINQ syntax is designed specifically to make operations on the sequence monad feel natural, but in fact the implementation is more general; what C# calls "SelectMany" is a slightly modified form of the "Bind" operation on an arbitrary monad.
Если вы не написали IDE, которая на ходу переводит все идентификаторы и стандартной и сторонних билиотек JS/TS в snake, вероятно, нам надо читать раздел смешение стилей?
А вообще, вы можете сравнить концептуально $mol c каким-то близким фреймворком — он действительно несет что-то новое? Вот автор постоянно постит статьи типа "всего за полчаса я сделал аналог экселя" — там действительно есть какие-то высокоуровневые абстракции которых нет у других или это что-то еще?
И еще. Во фронтенде это принято постоянные префиксы вот такие? Вместо "мама мыла раму" "$mol_мама $mol_рыла $mol_маму"
Извините, я не фронтендер. Перехват хоткеев будет работать только в том случае если производитель браузера имеет такие же взгляды на хоткеи как и производитель приложения?
Выполнение LINQ-запроса легко делегируется другой части системы, что в ORM-аспекте и сделано.
Тут я имею ввиду уровень абстракции на котором определен интерфейс канала (КМК это то же самое что и "порт" в рамках hexagonal architecture)
А в чём профит?
Я встречал два варианта:
Допустим у вас есть какой-то модуль, который может хранить свои данные и в SQL и в плоских файлах. Если сделать "слой query" легко подменяемым (фактически — репозиторий) то можно легко заменять его реализации другими полностью — там где был сложный LINQ с джоинами будет, например вызитывание какого-нибудь смещения в файле. Чтобы по подменить реализации не придется поддерживать linq поверх этих файлов.
Допустим вы разрабатывали какой-то модуль на одной субд, и портировали на другую. В другой субд оказался такой оптимизатор, что некоторые запросы пришлось разбивать на несколько. Например в одной быстрее джоин 5 таблиц, а во второй вычитка данных из первых двух, а потом запрос к остальным трем.
Как будет выглядеть трюк с хуками в данном случае? Будет ли он типобезопасным?
Нет "слоя" query.
Наверное, я использовал неправильный термин. Имелся ввиду "Query extensions"
Query extensions can be placed everywhere. Their intention is to replace read abstractions (Repositories) in software design.
Логически он есть так как у вас есть типа "статический репозиторий" где собраны типовые запросы. Я не вижу механизма который воспрепятствовал бы обращению из бизнес кода к linq напрямую. Вопрос заключается в том, считается ли хорошей практикой из бизнес кода ходить в linq мимо этих репозиториев?
Так у него всё равно ведь будет преимущество, потому что он его и на практике попробовал, и разобрался конкретно с ним в теории.
Да, поэтому интересно насколько большая эта разница.
Так если они в работе нужны, а Петя в них не шарит, то, может, ну, он вообще не подходит?
Да, именно чтобы его отбраковать так и надо делать.
А зачем её уменьшать?
Потому, что все равно конкретный алгоритм который нужен будет на работе скорее всего будет отличаться от того, который будет на собеседовании. Важнее ваша способность решать класс задач, а не конкретную задачу. Скорее всего на работе вы будете получать задачи из какого-то класса, возможно гуглить как их люди в принципе решают, выбирать наиболее применимый для вас способ решения и реализовывать.
Так, может, просто на собеседовании дать стихотворение какого-нибудь неизвестного поэта, а через 40 минут его попросить рассказать по памяти?
Это не про память а про способность понять.
И Петя, который никогда эти плюсы в жизни не видел, тоже нагугливает, зачем же нужен виртуальный деструктор, радостно вам оттарабанивает, и все счастливы.
Дальше вы можете проверить, Петя просто воспроизводит текст как попугай или понимает о чем идет речь, например. Ну это, скорее, к джунам.
Я не знаю, что там были за задания, но конкретно у меня такие соображения.
В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.
Или например, Вася недавно этот алгоритм использовали, а вы использовали несколько другой и у Васи будет преимущество. А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать. Вот чтобы отличить вас с Васей от Пети можно вам дать тему для подготовки, чтобы уменьшить вашу разницу с Васей.
Хотя это может у меня такая работа где все время что-то новое и надо учиться (хотя какой-то маломобильный фундамент помогает), а у вас — заучил на всю жизнь и пользуйся.
А что прочитать, чтобы выучить социальные взаимодействия — непонятно.
Пытались ли вы гуглить ответ на этот вопрос? Вообще это лучше тренировать и чтобы рядом был человек, который может посмотреть на вас со стороны и дать обратную связь.
Если все относятся друг к другу доброжелательно и хотят закоммитить качесвенный код, то ревью воспринимается как помощь. Принципиальные разногласия случаются редко, кратковременные случаются, но обычно решается аргументами.
Если мне не надо дифференцировать, у меня есть Exception
А как потом происходит их обработка? Например, через несколько уровней?
А можно немножко расшифровать предлагаемый подход.
Вот допустим у нас есть класс AuthorizationService который где то там использует метод GetUser.
Этот метод GetUser должен быть на интерфейсе, допустим, IUserRepository у которого две реализвации EntityFrameWorkUserRepository и XmlFileUserRepository.
С точки зрения существующего C# какие монады
Еще интересно было бы узнать, как это предлагается сделать в языке мечты автора.
Эта система называется в Windows "Microsoft Store". Достаточно перейти по ссылке и там есть все. Если у кого-то не получается этим воспользоваться то самим терминалом он не сможет пользоваться просто потому, что это техническая программа.
Собирали на венде — в символах виндовые пути
Наверное, наоборот, какой из mol а какой нет. Какой из нестандартной но не вашей библиотеки, наверное, не позволяет.
https://weblogs.asp.net/dixin/category-theory-via-csharp-7-monad-and-linq-to-monads
As Brian Beckman said in this Channel 9 video:
Eric Lippert also mentioned:
Если вы не написали IDE, которая на ходу переводит все идентификаторы и стандартной и сторонних билиотек JS/TS в snake, вероятно, нам надо читать раздел смешение стилей?
А вообще, вы можете сравнить концептуально $mol c каким-то близким фреймворком — он действительно несет что-то новое? Вот автор постоянно постит статьи типа "всего за полчаса я сделал аналог экселя" — там действительно есть какие-то высокоуровневые абстракции которых нет у других или это что-то еще?
И еще. Во фронтенде это принято постоянные префиксы вот такие? Вместо "мама мыла раму" "$mol_мама $mol_рыла $mol_маму"
Можно писать
Да, попробуйте сами на https://sharplab.io/
А так:
Извините, я не фронтендер. Перехват хоткеев будет работать только в том случае если производитель браузера имеет такие же взгляды на хоткеи как и производитель приложения?
nin-jin сравнивал разные подходы в вебе https://habr.com/ru/post/514144/ там, правда, нет про оверрайд Ctrl+F
Тут я имею ввиду уровень абстракции на котором определен интерфейс канала (КМК это то же самое что и "порт" в рамках hexagonal architecture)
Я встречал два варианта:
Допустим у вас есть какой-то модуль, который может хранить свои данные и в SQL и в плоских файлах. Если сделать "слой query" легко подменяемым (фактически — репозиторий) то можно легко заменять его реализации другими полностью — там где был сложный LINQ с джоинами будет, например вызитывание какого-нибудь смещения в файле. Чтобы по подменить реализации не придется поддерживать linq поверх этих файлов.
Допустим вы разрабатывали какой-то модуль на одной субд, и портировали на другую. В другой субд оказался такой оптимизатор, что некоторые запросы пришлось разбивать на несколько. Например в одной быстрее джоин 5 таблиц, а во второй вычитка данных из первых двух, а потом запрос к остальным трем.
Как будет выглядеть трюк с хуками в данном случае? Будет ли он типобезопасным?
Наверное, я использовал неправильный термин. Имелся ввиду "Query extensions"
Логически он есть так как у вас есть типа "статический репозиторий" где собраны типовые запросы. Я не вижу механизма который воспрепятствовал бы обращению из бизнес кода к linq напрямую. Вопрос заключается в том, считается ли хорошей практикой из бизнес кода ходить в linq мимо этих репозиториев?
Да, поэтому интересно насколько большая эта разница.
Да, именно чтобы его отбраковать так и надо делать.
Потому, что все равно конкретный алгоритм который нужен будет на работе скорее всего будет отличаться от того, который будет на собеседовании. Важнее ваша способность решать класс задач, а не конкретную задачу. Скорее всего на работе вы будете получать задачи из какого-то класса, возможно гуглить как их люди в принципе решают, выбирать наиболее применимый для вас способ решения и реализовывать.
Это не про память а про способность понять.
Дальше вы можете проверить, Петя просто воспроизводит текст как попугай или понимает о чем идет речь, например. Ну это, скорее, к джунам.
Я не знаю, что там были за задания, но конкретно у меня такие соображения.
В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.
Или например, Вася недавно этот алгоритм использовали, а вы использовали несколько другой и у Васи будет преимущество. А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать. Вот чтобы отличить вас с Васей от Пети можно вам дать тему для подготовки, чтобы уменьшить вашу разницу с Васей.
Хотя это может у меня такая работа где все время что-то новое и надо учиться (хотя какой-то маломобильный фундамент помогает), а у вас — заучил на всю жизнь и пользуйся.
Пытались ли вы гуглить ответ на этот вопрос? Вообще это лучше тренировать и чтобы рядом был человек, который может посмотреть на вас со стороны и дать обратную связь.
А почему собственно это плохо. Возможно их интересует ваша способность подготовиться?
Если все относятся друг к другу доброжелательно и хотят закоммитить качесвенный код, то ревью воспринимается как помощь. Принципиальные разногласия случаются редко, кратковременные случаются, но обычно решается аргументами.