проводить вычисление на сервере или на клиенте?
716
21
у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:
- высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
- либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.
Lancer.Rev.X сказал(а):↑у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:
- высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
- либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.
Нажмите, чтобы раскрыть...Яб если он уже получает всё что надо для вычисления считал на клиентской стороне чтобы разгрузить сервер. В теории я думаю тысяче юзеров проще сделать одно действие чем одному серверу тысячу.
lexani4321 сказал(а):↑Яб если он уже получает всё что надо для вычисления считал на клиентской стороне чтобы разгрузить сервер. В теории я думаю тысяче юзеров проще сделать одно действие чем одному серверу тысячу.
Нажмите, чтобы раскрыть...да у меня будет 3-4 юзера максимум, вопрос чисто эстетический, не правильнее ли будет логику поместить в МОДЕЛЬ ко всей остальной логике?
Lancer.Rev.X сказал(а):↑у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:
- высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
- либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.
Нажмите, чтобы раскрыть...Никаких вычислений на фронтенде.
Представь, что фронт открыл форму, и сидит и думает, что делать.А тем временем остальные не дремлют и кто-то из других пользователей тоже продает этот же продукт?
1) Даже если ты сделаешь проверку на клиенте, то сервер все равно должен проверить, не прислал ли клиент фигню, поэтому от проверки на клиенте пользы примерно 0
2) На клиенте вообще не должно быть никакой логики, это всего лишь вьюха, вся бизнес логика должна находиться на бэке
3) Код на клиенте находится в открытом доступе ( в браузере), поэтому даже в плане безопасности нельзя делать никаких вычислений на клиенте
Jaood сказал(а):↑На фронте не должно ничего вычисляться, что не касается непосредственно фронта.
Так что тут ответ очевиден.
Нажмите, чтобы раскрыть...я еще забыл написать, что этот флажок нужен только для того, чтобы показать его пользователю, на логику он никак не влияет, все равно его вычислять на сервере?
Lancer.Rev.X сказал(а):↑у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:
- высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
- либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.
Нажмите, чтобы раскрыть...на фронтенде не должно быть никаких вычислений и логики.
все на беке. идеальный фронт это верстка + анимации + rest api + стейт менеджер (только для стейта, сеттеров и геттеров, никаких вычислений).
представь что есть единый бекенд, и есть твой фронт а есть еще 5 разработчиков со своим фронтом.
как лучше думаешь будет?
все вычислять на сервере и отдавать json файл с данными которые нужно просто вывести.
или же так же делать какие то вычисления на серваке + отдавать json + еще на клиенте дополнительные вычисления, и хрен пойми какие.
Lancer.Rev.X сказал(а):↑я еще забыл написать, что этот флажок нужен только для того, чтобы показать его пользователю, на логику он никак не влияет, все равно его вычислять на сервере?
Нажмите, чтобы раскрыть...да, на фронт ты передаешь например json объект с атрибутами, где атрибут твоего флажка будет true / false. и уже в зависимости от этого отображаешь так как тебе нужно
Lancer.Rev.X сказал(а):↑а если у меня между таблицами связи многие ко многим, я же правильно делаю, что отправляю данные с id из другой таблицы, а потом на клиенте беру данные из второй таблицы по этому id? вот я нарисовал стрелочки:
Спойлер: "картинка со стрелочками"Нажмите, чтобы раскрыть...Это нарушает принципы mvc.
У тебя на фронте только вьюха. Единственное что она должна делать, что следует из названия, это отображать данные.
Абсолютно все вычисления, связи и тд, должны оставаться на беке, а на выходе на вьюху подаются уже подготовленные и обработанные данные.
Вьюха должна быть на столько же "глупая" в своих вычислениях как маленький ребенок.
Ты даёшь лист А3, на котором уже заполнена таблица. Всё что от ребенка ты имеешь право требовать - нарисовать красивую рамочку фломастерами.
Lancer.Rev.X сказал(а):↑а если у меня между таблицами связи многие ко многим, я же правильно делаю, что отправляю данные с id из другой таблицы, а потом на клиенте беру данные из второй таблицы по этому id? вот я нарисовал стрелочки:
Спойлер: "картинка со стрелочками"Нажмите, чтобы раскрыть...не понятно, т.е. ты берешь и каждый раз отправляешь запрос на переформирование таблиц смежных, не было бы проще просто составить один большой запрос, а данные делить уже на клиенте, какие отображать какие нет?
Я конечно не силен в вебе, но в 1с подавляющее большинство вещей, делается фильтрами на стороне клиента, но при определенных моментах ты переспрашиваешь данные с сервера(переоткрытие страницы, нажатие некоторых кнопок вроде обновить данные и прочее)
почитай про левый и правый join с общим join в sql, мб кота потом ставить не будешь...
Zly chlopak сказал(а):↑не понятно, т.е. ты берешь и каждый раз отправляешь запрос на переформирование таблиц смежных, не было бы проще просто составить один большой запрос, а данные делить уже на клиенте, какие отображать какие нет?
Я конечно не силен в вебе, но в 1с подавляющее большинство вещей, делается фильтрами на стороне клиента, но при определенных моментах ты переспрашиваешь данные с сервера(переоткрытие страницы, нажатие некоторых кнопок вроде обновить данные и прочее)
Нажмите, чтобы раскрыть...я отправляю клиенту сперва список продуктов с названиями, клиент заносит их в свою таблицу, потом отправляю список заказов, у каждого из которых есть ID продукта, клиент записывает в свою таблицу заказы и вписывает названия продуктов из заполненной ранее таблицы с продуктами.
потом еще эти продукты, материалы и заказы могут меняться другими клиентами, например, кто нибудь переименует один из продуктов, я отправляю клиенту сообщение, что продукт переименован, клиент у себя в таблице меняет название продукта и потом еще проверяет таблицу заказов и там тоже где надо меняет название продукта.
либо, если не заставлять клиента ничего самостоятельно делать, придется ему отправить второе сообщение об изменении названия продукта в заказе.
Lancer.Rev.X сказал(а):↑у моего списка мебели есть такой флажок: «можно ли собрать данный продукт?». он высчитывается в зависимости от наличия нужных материалов на складе. в МОДЕЛИ у меня есть функции «получить продукты» и «получить материалы», я вот думаю, как лучше:
- высчитывать флажки на сервере и передавать их вместе со всеми продуктами функцией «получить продукты»,
- либо посчитывать у клиента, у меня так получается, что клиент энивэй закачивает и продукты, и материалы, поэтому флажки может сам высчитать.
как правильнее сделать? реализацию обоих вариантов я вроде бы продумал, там все нормально сходится, проблем реализации ни в одном случае не будет.
Нажмите, чтобы раскрыть...только сервер
Jaood сказал(а):↑Это нарушает принципы mvc.
У тебя на фронте только вьюха. Единственное что она должна делать, что следует из названия, это отображать данные.
Абсолютно все вычисления, связи и тд, должны оставаться на беке, а на выходе на вьюху подаются уже подготовленные и обработанные данные.
Вьюха должна быть на столько же "глупая" в своих вычислениях как маленький ребенок.
Ты даёшь лист А3, на котором уже заполнена таблица. Всё что от ребенка ты имеешь право требовать - нарисовать красивую рамочку фломастерами.
Нажмите, чтобы раскрыть...я сделал, как ты сказал, передал клиенту полностью готовые к употреблению данные, код клиента стал максимально примитивным, так как таблицы теперь никак не зависят друг от друга, но только у меня не получилось сделать такую же структуру таблицы с продуктами, как я хотел (как на предыдущей картинке), по крайней мере я не нашел возможность сделать материалы в виде колонок, не передавая для них отдельный массив, вот, что получилось
Спойлер:это нормально, что я не могу сделать так, как вижу, выполняя условия шаблона mvc? и еще я ранее не упоминал, что я использую websocket, и клиент во время работы принимает сообщения и обновляет отдельные данные, а также отправляет сообщения, мб мне не подходит данный шаблон.
но код клиента получился намного проще, думаю, это точно позитивно повлияет на процесс разработки
Lancer.Rev.X сказал(а):↑я сделал, как ты сказал, передал клиенту полностью готовые к употреблению данные, код клиента стал максимально примитивным, так как таблицы теперь никак не зависят друг от друга, но только у меня не получилось сделать такую же структуру таблицы с продуктами, как я хотел (как на предыдущей картинке), по крайней мере я не нашел возможность сделать материалы в виде колонок, не передавая для них отдельный массив, вот, что получилось
Спойлер:это нормально, что я не могу сделать так, как вижу, выполняя условия шаблона mvc? и еще я ранее не упоминал, что я использую websocket, и клиент во время работы принимает сообщения и обновляет отдельные данные, а также отправляет сообщения, мб мне не подходит данный шаблон.
но код клиента получился намного проще, думаю, это точно позитивно повлияет на процесс разработки
Нажмите, чтобы раскрыть...Mvc лишь подразумевает что ты всю бизнес логику переносишь на сервер. Ты точно так же можешь запрашивать отдельные колонки на сервере.
Это никак не ограничивает функционал.
Если я правильно понял твою проблему с редактированием данных, то ты можешь выстроить такую цепочку событий.
Клиент начинает редактировать на клиенте ->
клиент завершает редактирование на клиенте ->
ты отправляешь тот кусок данных, которые клиент отредактировал ->
сервер отработал изменения в базе ->
сервер вернул тебе новую версию таблицы ->
ты обновил представления таблиц на клиенте.
Jaood сказал(а):↑Mvc лишь подразумевает что ты всю бизнес логику переносишь на сервер. Ты точно так же можешь запрашивать отдельные колонки на сервере.
Это никак не ограничивает функционал.
Если я правильно понял твою проблему с редактированием данных, то ты можешь выстроить такую цепочку событий.
Клиент начинает редактировать на клиенте ->
клиент завершает редактирование на клиенте ->
ты отправляешь тот кусок данных, которые клиент отредактировал ->
сервер отработал изменения в базе ->
сервер вернул тебе новую версию таблицы ->
ты обновил представления таблиц на клиенте.
Нажмите, чтобы раскрыть...для построения таблицы, как на первой картинке, клиент должен по сути сам соотнести рецепт продукта по айди материала с названием материала, структура данных такая:
Спойлер: "данные для картинки 1"это же получается уже связь, а ты говоришь, что все связи должны быть на сервере
вот по твоему совету я отправил такие данные уже готовые к отображению
Спойлер: "данные для картинки 2"тут получается, что такую таблицу, как на первой картинке, с колонками - материалами, уже не сделать, а также имена материалов дублируются, это получается лишний расход трафика, с заказами также, там дублируются имена продуктов, но зато все связи на сервере
Спойлер: "два варианта структуры данных заказов"
Lancer.Rev.X сказал(а):↑тут получается, что такую таблицу, как на первой картинке не сделать, а также имена материалов дублируются, это получается лишний расход трафика, с заказами также, там дублируются имена продуктов, но зато все связи на сервере
Нажмите, чтобы раскрыть...Не очень-то и большой "лишний расход". Тебе же не обязательно всю таблицу каждый раз отправлять, а только те части, которые нужно обновить.
Тема закрыта
-
ЗаголовокОтветов ПросмотровПоследнее сообщение
-
Сообщений:2
Просмотров:4
-
Сообщений:1
Просмотров:0
-
Сообщений:7
Просмотров:7
-
Сообщений:12
Просмотров:15
-
Сообщений:16
Просмотров:18