А есть у вас возможность расписать полностью конфигурацию серверов, на которой получилось 200 тыс запросов / мин достигнуть?
То есть — сколько вебов, сколько db серверов, сколько кешей приложения и кешей сессий — и на каких инстансах AWS каждый.
Стоимость в месяц всего вместе вы уже оценивали? :)
для Smart TV потребуется один метод:
— /catalog/{pageId} — возвращает html page
для Xbox/IE потребуется два метода:
— /api/catalog/{parameters set} — возвращает json для infinite scrolling
— /catalog — возвращает html page, нет input параметров
Вы предлагаете для обоих случаев пользоваться одним методом — - /catalog/{pageId}
Это возможно, но не правильно. Объясню почему.
Вы отдаете приложение на QA, они на xbox IE набирают /catalog/2 и выписывают дефект примерно следующего содержания: «как бы дитя не скролилло, любимых медведей не увидело». У Вас два пути решения проблемы:
— сделать для xbox метод без параметра
— сделать в контроллере условную логику основанную на том какой девайс/браузер используется, что является не верным решением. Именно от этого и следует уходить любыми средствами. Аналогичная условная логика во View также не желательна — поэтому MS и сделали View Modes в MVC 4.
Это спор аналогичный тому стоит ли пытаться на HTML 5 делать одно приложение работающее и на iOS, и на Android, и на Windows Phone 8. Ответ на него очень простой — если Вам нужен WoW результат и ресурсы позволяют, то нужно делать для каждой платформы нативное приложение.
С сайтом ситуация аналогичная. Если Вы хотите быть удобными для пользователей, если хотите чтобы пользователи открывали Ваш сайт пока сидят в туалете, дома перед выпуском новостей, пользовались вашим сайтом с нескольких устройств одновременно — то Вам придется делать сайт опираясь на возможности каждой из платформ. Сайт — это такое же приложение.
В то же время открывать большенство сайтов на мобильных устройствах, телевизорах и приставках практически бесполезно, т.к. меню разворачивается на mouse over, комбобоксы закрываются до того как вы проскроллите до нужного пункта и автоматически уходит пост-бек, чтобы добраться до кнопки ОК нужно 25 раз нажать на кнопку Вниз, а на link button никак не попасть с джойстика. И все эти сайты не парятся по этому поводу :)
Я бы всем посоветовал запарится, потому что другой возможности сейчас как-то выделится из десятков тысяч аналогов — нет.
В условиях конкуренции выигрывает тот, кто к лесу задом, а к пользователю передом.
Я бы сказал что различие в том, что
— для infinite scrolling у нас есть action method который принимает параметры и отдает JSON
— а для постраничного пейджинга у нас есть action method который отдает aspx/cshtml View, причем размер страницы в элементах фиксированный и не должен передаваться через параметры — у пытливого пользователя не должно быть возможности этим управлять.
Передавать параметр в метод управляя тем в каком формате отдавать результат или опираться на content-type запроса в данном случае не верно.
У Вас может использоватся одна и таже логика пейджинга, но методы контроллера — это presentation layer. Они будут разными и это правильно. Здесь не нужно стремиться делать универсальные механизмы.
Да, приведу пример на странице показывающей пользователю ассортимент товара — обычный browse list с картинками товаров.
Оптимальным подходом будет следующее:
Для XBOX мы показываем товар как обычно, ширина фиксирована, пейджинг нам не нужен — пользователь пролистывает страницу вниз и мы всевремя подгружаем вниз товар для показа (infinite scrolling). Страница может содержать виджеты социальных сетей, кнопки рейтинга товара и тому подобное.
Для SmartTV — ширина та же, но необходимо избавится от скроллинга, товар показывается постранично, все умещается на страницу без скроллинга, слева и справа страницы кнопки Влево/Вправо, в JavaScript обрабатываем key press events с кнопок пульта и делаем пост-беки для пейджинга. Никаких виджетов.
То есть и сама страница, ее функционал и внешний вид, а также server side для педжинга будут различными.
Совершенно верно! Я тоже сталкивался с тем, что валидация email адресов не пропускает домены .travel Нужно все регулярные выражения которыми производится валидация email-ов тестить на .travel
Я забыл уточнить, что разницы между ними нет с точки зрения продавца :)
Sales Tax в US, так же как и VAT (НДС у нас), перекладываестя на покупателя, увеличивая стоимость товара на опредененный процент. Если товар продается повторно (used goods), то Sales Tax взымается повторно — так же как и VAT.
Разница между ними только в том, что:
— размер VAT включен в retail price, а ценники в US не содержат Sales Tax; в России цены также могут не содержать в себе НДС.
— VAT (НДС) закладывается в цену начиная с производства и переклывается вверх по цепочке продажи по-очереди, пока не дойдет до покупателя, который его собственно и заплатит.
То есть VAT отличается от Sale Tax в методике расчета. Но для последнего звена — продавца — оба налога обслуживаются одинаково. Для покупателя оба налога также суть одно и тоже, так как ему приходится заплатить больше на определенный процент.
Есть еще разница в том куда идет сумма налога, но это с точки зрения продавца уже не важно :)
Кластеризация веб приложений на хостинге Amazon Web Services
То есть — сколько вебов, сколько db серверов, сколько кешей приложения и кешей сессий — и на каких инстансах AWS каждый.
Стоимость в месяц всего вместе вы уже оценивали? :)
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
для Smart TV потребуется один метод:
— /catalog/{pageId} — возвращает html page
для Xbox/IE потребуется два метода:
— /api/catalog/{parameters set} — возвращает json для infinite scrolling
— /catalog — возвращает html page, нет input параметров
Вы предлагаете для обоих случаев пользоваться одним методом — - /catalog/{pageId}
Это возможно, но не правильно. Объясню почему.
Вы отдаете приложение на QA, они на xbox IE набирают /catalog/2 и выписывают дефект примерно следующего содержания: «как бы дитя не скролилло, любимых медведей не увидело». У Вас два пути решения проблемы:
— сделать для xbox метод без параметра
— сделать в контроллере условную логику основанную на том какой девайс/браузер используется, что является не верным решением. Именно от этого и следует уходить любыми средствами. Аналогичная условная логика во View также не желательна — поэтому MS и сделали View Modes в MVC 4.
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
С сайтом ситуация аналогичная. Если Вы хотите быть удобными для пользователей, если хотите чтобы пользователи открывали Ваш сайт пока сидят в туалете, дома перед выпуском новостей, пользовались вашим сайтом с нескольких устройств одновременно — то Вам придется делать сайт опираясь на возможности каждой из платформ. Сайт — это такое же приложение.
В то же время открывать большенство сайтов на мобильных устройствах, телевизорах и приставках практически бесполезно, т.к. меню разворачивается на mouse over, комбобоксы закрываются до того как вы проскроллите до нужного пункта и автоматически уходит пост-бек, чтобы добраться до кнопки ОК нужно 25 раз нажать на кнопку Вниз, а на link button никак не попасть с джойстика. И все эти сайты не парятся по этому поводу :)
Я бы всем посоветовал запарится, потому что другой возможности сейчас как-то выделится из десятков тысяч аналогов — нет.
В условиях конкуренции выигрывает тот, кто к лесу задом, а к пользователю передом.
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
— для infinite scrolling у нас есть action method который принимает параметры и отдает JSON
— а для постраничного пейджинга у нас есть action method который отдает aspx/cshtml View, причем размер страницы в элементах фиксированный и не должен передаваться через параметры — у пытливого пользователя не должно быть возможности этим управлять.
Передавать параметр в метод управляя тем в каком формате отдавать результат или опираться на content-type запроса в данном случае не верно.
У Вас может использоватся одна и таже логика пейджинга, но методы контроллера — это presentation layer. Они будут разными и это правильно. Здесь не нужно стремиться делать универсальные механизмы.
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
Оптимальным подходом будет следующее:
Для XBOX мы показываем товар как обычно, ширина фиксирована, пейджинг нам не нужен — пользователь пролистывает страницу вниз и мы всевремя подгружаем вниз товар для показа (infinite scrolling). Страница может содержать виджеты социальных сетей, кнопки рейтинга товара и тому подобное.
Для SmartTV — ширина та же, но необходимо избавится от скроллинга, товар показывается постранично, все умещается на страницу без скроллинга, слева и справа страницы кнопки Влево/Вправо, в JavaScript обрабатываем key press events с кнопок пульта и делаем пост-беки для пейджинга. Никаких виджетов.
То есть и сама страница, ее функционал и внешний вид, а также server side для педжинга будут различными.
ASP.NET MVC 4 Mobile Features устарели быстрее чем появились
Валидация форм с почтовыми адресами — не забывайте про Гонконг
Валидация форм с почтовыми адресами — не забывайте про Гонконг
Sales Tax в US, так же как и VAT (НДС у нас), перекладываестя на покупателя, увеличивая стоимость товара на опредененный процент. Если товар продается повторно (used goods), то Sales Tax взымается повторно — так же как и VAT.
Разница между ними только в том, что:
— размер VAT включен в retail price, а ценники в US не содержат Sales Tax; в России цены также могут не содержать в себе НДС.
— VAT (НДС) закладывается в цену начиная с производства и переклывается вверх по цепочке продажи по-очереди, пока не дойдет до покупателя, который его собственно и заплатит.
То есть VAT отличается от Sale Tax в методике расчета. Но для последнего звена — продавца — оба налога обслуживаются одинаково. Для покупателя оба налога также суть одно и тоже, так как ему приходится заплатить больше на определенный процент.
Есть еще разница в том куда идет сумма налога, но это с точки зрения продавца уже не важно :)
Валидация форм с почтовыми адресами — не забывайте про Гонконг