Быть может я что-то не так делаю?
Сервис я регистрирую в стартапе вот так: services.AddScoped<RolesValidation>();
В таком случае конструктор отрабатывает один раз (разумеется, ниакие роли в него не передаются). Далее, при выполнении метода контроллера заходит только в метод CreateInstance.
Сейчас попробую с AddTransient
Иван Шумов, Иван, я не пойму, что вы пытаетесь тут обсудить. "Системные аналитики" так же размазанное определение, как и клиентские менеджеры, они в разных компаниях могут заниматься совершенно различными, даже противоположными вещами. не подразумевает серьезную умственную деятельность для работы с системами анализа - окей, ранее было сказано, что для таких людей и пишется этот инструмент.
Вы в который раз твердите, что проще под каждый новый отчёт делать свою хранимку, апи, плюс веб часть. (И потом тратить силы на сопровождение). Я говорю, что проще сделать универсальный конструктор под все такие отчёты, тем более, что им смогут пользоваться простые смертные, кто не знает sql. Я выслушал ваше мнение, принял его, тем не менее, оно не относится к вопросу, заданному изначально, хватит это обсуждать.
Иван Шумов, Дискутировать можно бесконечно. Не очень понимаю, зачем этим заниматься, но ладно )
Вы говорите отличную фразу: "Любое решение должно закрывать потребность, а не делать ту же работу, но иначе." Тут же приводите аргумент, какую проблему закрывает данный инструмент: "Визуальный построитель запросов может закрывать только одну проблему - отсутствие квалификации пользователя."
Отлично, вы сами себе доказали, что идея не бесполезна, а решает целую проблему!
И даже указали на целевую аудиторию, этим инструментом будут пользоваться не программисты, а я добавлю, системные аналитики и даже клиентские менеджеры, если им еще инструкцию написать.
Замечательно
Иван Шумов, так я, вроде, сразу и написал, что не умею ) умел бы, не спрашивал бы ))
Пока это всё на уровне идеи, поэтому еще ничего не проверял. Смотрю, как подобные задачи решаются, какие методы вообще существуют. то-то не умеет в колоночные базы данных - ну я не умею, Иван, к чему оскорбления и к чему эти пустые обсуждения? занимается предполагаемой оптимизацией - кто занимается? Я лишь сказал, что если в отчете шесть колонок из двух таблиц, то конкретный запрос для этого отчёта будет содержать 6 колонок и один джоин и это будет быстрее, чем использовать под данный отчёт какой-то общий запрос, который будет содержать 250 полей и 13 джоинов, это и ежу понятно.
В своём вопросе я уже предложил три варианта, надеюсь, что мне подскажут какие-то другие варианты. Или хотя бы скажут, чувак, я делал вьюху, да, пришлось немного пожертвовать производительностью, ради удобства, но это стоило того, потому что вот так. И мы сделали еще вот это и всё вообще супер стало.
А вот эти обсуждения "хаха, кто-то не умеет в колоночные бд" - к чему? стыдно должно быть
ayazer, давным-давно перешёл на linq, понял прелесть типизации. Тяжело сопровождать, могут быть опечатки всякие, кто-то внёс правочку, у каких-то клиентов что-то отвалилось ) в целом, можно, конечно
Есть старая система, в которой под каждый такой отчёт для разных клиентов делают хранимку. Многие такие отчёты реально различаются на пару полей. Отчётами пользуются. Очень много времени на сопровождение, как вы понимаете.
Хотят сделать новую систему и исправить такую ситуацию.
Я не говорил, что сам клиент будет тыкать какие-то галки, но эту работу смело можно переложить с разработчиков на клиентских менеджеров.
Единственный момент, если я сделаю здоровенную общую вьюху, она будет работать медленнее (мне кажется сильно медленнее, но я не проверял), чем запрос под конкретный отчёт. То есть, появится такой же отчёт, который был, но будет загружаться полминуты, так я не хочу
Не согласен. Мы как-то пилили учебный проект, собирались в субботу часа на четыре раз в 2-3 недели, плюс кто как вечерами когда захочет. Проект на ангуляре + .net core, некоторые участники ангуляр в принципе не знали. Были тестировщики слабой руки, даже аналитики, которые хотели попробовать в программирование. Опытный разработчик не будет тратить время на потенциального конкурента - категорически не согласен с таким утверждением. Есть сеньёр/тимлид/архитектор и есть миддлы/джуны/околопрограммисты, пусть с других отделов. Это не конкуренты, цель проекта увеличить опыт коллег (в основном были с одной конторы, но с разных отделов, но были и просто знакомые, которые принимали участие). Даже если пофантазировать, вдруг "ученик превзойдёт своего учителя" - это прекрасно, но такого человека не сделают тимлидом другого отдела, да, он сможет уйти в другую организацию, но это не конкуренция никак.
Такие проекты полезны всем участникам. Если чувак шарит в программировании и может передать свой опыт, то нельзя говорить, что как ведущий он ничего не поимеет. Опыт выступлений можно получить только практикой. Структурирование занятий и так далее, это всё бесценный опыт. Так же, можно попробовать какие-то инструменты, которые не используются в основной работе, к примеру, можно взять бутстрап на фронте, разобрать реактивные формы или можно поработать с signal R, или какую-нибудь очередь поставить. Это полезно и интересно, попилить какой-то пет проект не одному и в стол, а с компанией заинтересованных лиц.
Есть другие примеры "зачем заниматься такой ерундой человеку, вроде как он с этого ничего не поимеет" - могу привести кружки робототехники. Я тут вижу полную аналогию с программированием. Некоторые из них именно некоммерческие, инфа о таких кружках передаётся через сарафанное радио и держится, внимание, исключительно на альтруизме руководителя. Зачем они этим занимаются? Быть может у некоторых появляется какая-то потребность в передаче знаний. Но я всё же думаю, что пилить что-то интересное в группе людей становится еще интересней! )
ThunderCat, ну да, так понятней, спасибо. То есть, если сайт не популярен, то это просто слепое следование успешным сайтам. Ну и если регистрируются именно почта/пароль, без всяких логинов, то смысла как бы и нет совсем
эм, не очень понимаю, ну раз разговор про почту, то она если и не является логином, то на этом поле обычно стоит уникальность.
То есть, вот появился пользователь, ему отправляется ссылка о подтверждении эмейла (или ссылка о регистрации). Допустим, она активна в течении 3 дней. Проходит это время и пользователю еще раз требуется отправлять ссылку. Ну и как бы, зачем там ограничение по времени? Ну через год пусть подтвердит, какая разница-то?
Я думал, что это как-то с безопасностью может связано? но ничего не придумал )
⚡ Kotobotov ⚡, ну нет, я категорически против травли. Конечно, любые идеи можно преподнести в разном виде в меру своих садистских наклонностей, в том числе и эту.
Если человеку незачем списывать время, то необходимо дать ему такие причины. Тем более, что списывание времени обычный нормальный рабочий процесс.
Ведь действительно существуют люди, которые нихрена не делают, извиняюсь за выражение. И если они разбегутся, то будет даже лучше. Те же люди, которые нормально работают, не сталкиваются с проблемой "куда бы списать времени".
Ну и повторюсь, любую идею можно так повернуть, что получится какой-нибудь ад.
а что смущает? where No_=@exchangeCode тоже должен присутствовать, я по одной записи разбираю. Точнее, может придти несколько строк с одним кодом, я беру данные из последнего сообщения по дате, а затем у всех записей по этому коду проставляю Processed. В общем, не понял этого "ээээ" )
