checky: По первому пункту - есть такое решение как https://ru.wikipedia.org/wiki/Redis и подобные. Если ваш список клиентов зависит от роли пользователя, а не сугубо индивидуальный - то кешируйте и будете ходить мимо базы для пользователей с одинаковыми ролями. По картинкам ничего однозначного сказать не могу. Можно написать контроллер, отдающий картинки по идентификатору и опять же использовать кеширование на уровне веб-сервера.
IPv4: Вам нужно написать класс, которые будет соответствовать структуре одного элемента вашего json.
Что-то вроде
class MyFirstClass{
MySecondClass[] items;
}
class MySecondClass
{
int key;
string value;
}
stoxx2011: А вам на заметку - в строго-типизированном языке где все типы определяются на этапе компиляции не может возникнуть нестрого-типизированная конструкция. То что компиляция может быть сделана на лету или то что вы написали var этого не отменяет, просто тип будет определен чуть позже и не вами.
stoxx2011: Неправы оба. Предлагаю вам 2 варианта на выбор - 1) Спустить методичку в унитаз и взять документацию. 2)Смять в комок и затолкать куда нибудь ее тому кто ее вам дал... и взять документацию.
Методы с приставкой For это просто ДРУГИЕ методы. Никакого отношения к типизации они не имеют, они разворачиваются в гораздо более сложные структуры, нежели простые методы. @Html.TextBoxFor(m=>m.Person) сгенерирует текстовое поле при любых условиях и от модели и от Person это не зависит. То что написано в методичке какой-то горячечный бред, после которого хочется руки помыть.
Роман Мирр: Та ссылка на stackoverflow, которую вы привели, курам на смех. Целевой бот без проблем можно научить склеивать атрибуты. А зачем свои? Да потому что придти с умным видом и учить какие решения нужно использовать, а какие нет - очень легко. А вот нести ответственность за лояльность клиентов, за положительный пользовательский опыт, за легкость поддержки системы - это уже совсем другое. Если бы у вас был высоконагруженный проект, который замечательно отшивает ботов и имеет толпу радостных клиентов - можно было бы ваше мнение принять за авторитет. А пока нет - вы один из тысяч специалистов, которые лучше всех знают как надо делать.
kiril901: Я не знаю что должно быть, я не знаю что вы хотите сделать, а самое главное - я не испытываю ни малейшего желания разбираться с вашими поделками. Разбирайтесь и с PHP и с SQL. А если возникнут проблемы - спрашивайте.
Amarg0: Ну а что вы вывести хотите? Вы знаете что компьютерное дробное число "малость" отличается от математического? Что есть понятие точности.Что компьютер не знает что такое "бесконечный период".
deniskutovskiy: Первый метод не дублирует дефолт под одной простой причине - ожидается исключительно рут из одного конкретного слова. А вообще это ваша система. Не пытайтесь ухватиться и за сиську и за письку одной рукой. Вы описали какой хотите урл, я написал какой нужен рут. То что у вас из-за этого рухнет другой урл, я знать не могу.
Дмитрий Гавриленко: Для всех скриптов или только для этого метода? вы говорили что там еще скрипты есть. Вообще я вам еще советовал придумать как сделать UPDATE одним запросом, а не 25. Для этого пишется хранимая процедурка, на вход которой подается таблица новых значений, а внутри делается 1 единственный скрипт вроде
UPDATE contractor
SET Responsible = t.newValue
FROM Contractor as C
JOIN @inputTable as t ON c.id = t.id
Ну и небольшой постскриптум - НИКОГДА не делайте последоватльное исполнение скриптов вызовом из серверного кода. Причина проста и банальна - есть такое понятия как лок таблицы и транзакции. Если этот ваш код на боевой системе рухнет - у вас база застрянет в полупозиции раком и хрен знает правильно это будет или нет, а уж откатить изменения сможете только случайно завалявшимся бэкапом. Если не умеете в хранимки и транзакции - возьмите Entity Framework. Он умеет накатывать изменения транзакцией.