Дмитрий Башинский, ну в документе их апи должен же быть полный пример ответа. Если его знать, то можно придумать какую угодно свою C# модель, ответ привести к JObject, пройтись по дереву и заполнить из него значениями свою модель. Не нужно никаких скобок менять, это не лучшее решение.
В общем, я бы сделал словарь Dictionary<string, ItemPrice>, только в ItemPrice добавил бы поле DateTime. Получается ключом было бы название товара, а название поля даты прайса перенес бы в модель самого прайса.
Stalker_RED, я допускаю что я слеп. Приведите мне пример, как с помощью json.net не десериализуя, конвертнуть к "{""key1"":""value1"",""key2"":""value2""}"
Stalker_RED, тот Json вполне корректный, все правильно. Когда я говорю "один тип к другому", я имею ввиду один json объект к другому json объекту. Что значит "никто не заставляет конвертировать"? А как ему на стороне сервера работать с этим ответом? Парсить регулярками или запускать js из C# кода? Даже когда его приведет к JObject, то это будет C# объект.
Мой вопрос к Вам заключался в том, что как ответ в формате json сконверировать к тому виду о котором Вы писали выше?
Stalker_RED, у него нет методов трансформации json в json. Можно конечно разобрать на JObject, рекурсивно в глубину пройтись, из всего этого поделать пары ключ-значение, но это равносильно если б я десериализовал к дайнемик, а потом рефлекшином вытянул названия полей и их значения и т.д. Вы сказали "сконвертируй", я решил, что у Вас есть опыт и решение. По своему опыту скажу, что нет в .net стандартных способов трансформации json. Есть одна майкрософтовская библиотека, но она на столько бедная по возможностям и не развивается, что на нее не стоит даже внимание обращать.
Сконвертировать в словарь:
string json = @"{""key1"":""value1"",""key2"":""value2""}";
Чем Вы порекомендуете его сконвертировать на стороне сервера?
Чтобы его сконвертировать средствами C# его нужно десериализовать, но этого Вы сделать не сможете с такими названиями полей и которые от каждого запроса будут разными. Даже dynamic тип не поможет.
Если подскажете вариант, буду признателен, потому что сталкивался с подобной задачей.
Т.к. по условию у Вас lenghtText = 1, то secondCharacter всегда будет равен firstCharacter, индекс для поиска вхождения сдвигаться никогда не будет.
Оставьте просто firstCharacter + lenghtText
this это текущий контекст объекта, т.е все его свойства и методы. Для объекта Slider в текущем контексте есть images и i. А вот для объекта на котором произошло событие this будет указывать на другой контекст, на свой и в этом контексте этих свойств уже не будет.
Поэтому чтобы обратиться к свойствам выше мы создаем локальную переменную, которой указываем ссылку на нужный нам контекст и через замыкание обращаемся к ней из другого контекста, контекста тех объектов на которых произошло событие.
Был у меня один легаси проект. Там проект ангуляра был внутри солюшена, но в другом проекте. Помню, что было не совсем удобно, т.к. сначала собирал ангуляровский проект, подменял все индекс файлы в asp батником, потом запускал asp и проверял.
Потому, наверное, удобнее всетаки в разных солюшенах и тогда можно нормально дебажить, запустив два проекта. Хотя, опять таки как подменять на лету индекс файлы...
Ярослав Сиваков, Ярик, и ты здесь)
Тут все дело в DDD подходе, который сейчас у многих на хайпе. А там даже логика формирования данных находится внутри доменной модели. В твоем случае логика формирования данных будет снаружи.
Вот есть про это дело «Domain Driven Design: профит малой кровью». Рассказывает не внятно, но в целом принцип понятен.
Павел, у меня был год опыта работы в проекте платежного шлюза: карточки, электронные платежи и все такое. Так вот у нас там как раз так и было, что если надо было клиенту отдать идентификатор платежа или сохраненных данных карты, или созданного рекурентного платежа, то отдавали мы ему специально созданный идентификатор, а не реальный с бд, но внутри проекта для работы использовали реальный. Почему, с ходу сказать не могу, почему то я это принял как данное, но теперь я поинтересуюсь тоже). Но дураков там не было точно, через шлюз шло до 1млрд руб в месяц.
FomaX, Плюсанул Ankhena, в принципе все правильно.
ограничивать мои идеи
Идеи должны быть заказчика, Вы можете предложить, а он может согласиться.
Опять веду к тому же. Мы делаем продукт для бизнеса, бизнес хочет заработать на продукте, значит продукт должен решать задачи бизнеса. При разработке продукта, при составления списка будущих фич, в первую очередь надо думать, а решает ли эта фича задачу бизнеса? Мы можем навернуть что-то супер-охренительно крутое, но решать задачу оно не будет лучше чем в более простом и соответственно дешевом виде.
Поэтому отталкиваться конечно надо от того функционала и целей продукта. Если для достижения цели требуются определенные фичи, которые будет невозможно, либо проблемно (а значит дорого) реализовать, то это и надо показать заказчику. Для заказчика стоимость продукта имеет значение. Поэтому, если Вы сможете ему показать, что wix не сможет решить его задачи, либо это в конечном итоге будет дороже, то если заказчик с умом, пересмотрит свои условия.
В общем, я бы сделал словарь
Dictionary<string, ItemPrice>, только в ItemPrice добавил бы поле DateTime. Получается ключом было бы название товара, а название поля даты прайса перенес бы в модель самого прайса.