Вход | Регистрация
 

Что делать с фронтом?

Что делать с фронтом?
Я
   Caber
 
27.10.21 - 07:34
Как некоторые здесь уже знают, я изучаю ASP.NET MVC. До этого был простым спецом по платформе 1С.
Сравнивая платформы 1С и фреймворк ASP+MVC, я все время поражаюсь, сколько же приходится писать на JS и html, чтобы создать обычные простые элементы управления и ввода.
К примеру - аналог поля ввода 1С с ссылочным типом данных. Справа есть кнопка выбора, нажатие на которую открывает форму выбора из списка целевых элементов. Это замечательно.
В ASP+MVC же мне приходится нарисовать поле ввода, прилепить скрытый input, который хранит в себе идентификатор выбранного объекта, на джаваскрипте обрабатывать начало выбора, выбор, открытие формы списка и окончание выбора, запрашивать данные целевых объектов с сервера ajax'ом.
Я не жалуюсь, что работы и кода очень много. Это не является проблемой. Меня не покидает ощущение того, что результат всего этого мартышкиного труда крайне ненадежен, трудно поддерживаем, не является универсальным для всех решений в будущем.
Разумеется, так как сейчас я учусь, я "зарылся". В следующем проекте, на основе полученных знаний, я начну эти элементы, части кода и верстки стандартизировать для себя, отделять зерна от плевел. Но опять же, ощущение, что все не так, что-то не то. Что есть либо готовые решения, либо более надежный способ создания фронт-енда для реляционных информационных баз.
Если вкратце - что лучше подходит из фронтенд-фреймворков для реляционных ИБ?
   ДенисЧ
 
1 - 27.10.21 - 07:38
А как связаны фронт-фреймы и базы данных? Фронт о базе вообще не должен знать. Он должен уметь позвать бек и показать полученные данные.
На чём там бек написано - на мускуле, оракле или монге, его вообще не должно волновать.
   Caber
 
2 - 27.10.21 - 07:48
(1) Ну, собственно, я и описал проблему с "позвать бек и показать полученные данные". Разумеется, фронт и бэк разделены друг от друга и выполняют свои задачи. Но если в бэкэнде все четко, по военному надежно, то на фронте творится какое-то лгбт.
   Garykom
 
3 - 27.10.21 - 08:14
(0) фреймворки
   MadHead
 
4 - 27.10.21 - 08:34
(2) В данном случае роль играют много факторов.

1. Под простые задачи типа CRUD существуют генераторы кода, которые нагенеривают заготовку фронта и бекенда. Я далек от С# но под джаву есть https://www.jhipster.tech/
2. Как правило на 1с и на C# делают решение разных ценовых сегментов, и судя по всему один однотипный дизайн на всех как в 1с ни сильно интересен более серьезным заказчикам
3. Если набить руку, то окажется, что не так уж и долго делать вами описанные операции.
   Смотрящий
 
5 - 27.10.21 - 08:54
(0) Клиента с сервера вызвать можешь ?
   rsv
 
6 - 27.10.21 - 09:02
(0) вы теперь фронтендер. Стили , разметка и тд.
Это отдельное направление. А хранимки в базе данных ( которые надо дергать)
напишут другие проги. Проги БД. Но есть и плюсы.
Если с 1с элемент  на форме кривоватый в браузере- ждем новый релиз платформы.
А вы быстренько поправите .
   Конструктор1С
 
7 - 27.10.21 - 09:09
(6) за хранимки в БД сейчас уже ругают. По архитектурным феншуям, бизнес-логика должна быть в доменном слое архитектуры, а не в слое БД. Иначе образуется жесткая привязка к определенной СУБД
   rsv
 
8 - 27.10.21 - 09:12
(7) ну если ругают …. Тогда фронтендеру скажут какие таблички дергать и
, куда апдейтить и какие тексты запросов должны быть . А скажут все теже проги БД
   ДенисЧ
 
9 - 27.10.21 - 09:13
(7) Фронту должно быть абсолютно пофигу, хранимки у тебя там или запросы в цикле. Он свой жисон (условный) получил и рисует.
   Конструктор1С
 
10 - 27.10.21 - 09:16
(9) не совсем так. Это бизнес-логике должно быть пофигу, с какой БД или облачной хрени в неё данные прилетают, и какой интерфейс у неё данные забирает. Фронт далеко не главный, главный слой доменной (бизнес) логики
   rsv
 
11 - 27.10.21 - 09:20
(0) ….. уже три в команде … фронтендер, тот кто фронтендеру собирает xml или json и прог БД .
Так что все не так плохо доя фронта.
   ДенисЧ
 
12 - 27.10.21 - 09:22
(10) О том и речь. фронт получил жисон. А от кого он его получил... МОжет, сегодня он с локалхоста берёт, а завтра на амазон полезет.
Речь о том, что фронт, хранимки и прочие дб - как-то фиолетово. Должно быть.
   Конструктор1С
 
13 - 27.10.21 - 09:24
(12) ладно, так тоже можно сказать. Фронт ничего не должен знать, как и откуда данные были получены
   pechkin
 
14 - 27.10.21 - 09:29
Для фронта тоже полно разных компонент. Все самому с 0 писать не обязательно
   pechkin
 
15 - 27.10.21 - 09:30
Фронт конечно лучше делать на слвременном фреймворке : реакт, вью, ангулар. Реакт из них самый популярный в коммерческой разработке
   Конструктор1С
 
16 - 27.10.21 - 09:30
Вспыл в памяти пример, как жесткая привязка архитектуры к БД вышла боком. Одно предприятие написало под себя нетленку (не на 1с, на этих ихних тру-языках). Нетленка очень понравилась руководству, и её было решили продавать другим предприятиям. Но вот беда, в нетленке много бизнес-логики сидело в хранимках oracle. На том и встали продажи. Не много нашлось желающих покупать нетленку и попутно дорогущие лицензии oracle. А сделали бы по-человечачи, сосредоточили разработчики бизнес-логику в доменном слое, клиенты сами могли бы выбрать, какую СУБД им использовать. Хошь постгрю, хош мускуль, хошь монгу. Потребовалась бы лишь небольшая переработка слоя взаимодействия с БД

Собственно, поэтому в 1с и никогда не завезут NoSQL. В 1сных конфах много бизнес-логики жестко врезалось в запросы к БД
   pechkin
 
17 - 27.10.21 - 09:33
(16) если нужна производительность то всяко придется затачивать под бд
   ДенисЧ
 
18 - 27.10.21 - 09:35
(15) "на слвременном фреймворке ... ангулар"
дядя, а вы Ленина видели?
   Kassern
 
19 - 27.10.21 - 09:35
вроде ТС о другом спрашивал, если какие то инструменты упрощающие работу с фронтом, как то так я его понял
   pechkin
 
20 - 27.10.21 - 09:38
(19) конечно есть. Готовых компонент полно.
Писать на реакте под бутстрап да с компонентами совмем не сложно. Практически ни о чем думать не надо
   Конструктор1С
 
21 - 27.10.21 - 09:39
(17) заточка во имя производительности это индексы таблиц, оптимальная структура таблиц, гранулярность блокировок и вот это всё. К бизнес-логике оно не имеет отношения
   pechkin
 
22 - 27.10.21 - 09:40
(21) ага кто поддерживает коррелированные запрсы, а кто-то нет. А ты их юзаешь ибо удобно
   pechkin
 
23 - 27.10.21 - 09:41
(21) или языковые индексы как в постре у ыузинв
   Конструктор1С
 
24 - 27.10.21 - 09:51
(22) ты сейчас смотришь на работу с БД глазами 1сника. 1сники в этом плане весьма своебразные. Дали нам пакетные запросы, а мы и рады писать километровые портянки. В тру-бэкенде так не принято, там стараются обходиться простыми CRUD-операциями. И живут же нормально, пишут сложные системы
   MadHead
 
25 - 27.10.21 - 09:52
(21) Приложение состоит не только из безнес логики. Естественно затачивать бизнес логику под БД не стоит, но слой слой инфраструктуры/адаптеров будет сложнее. Думаю об это речь.
   Kassern
 
26 - 27.10.21 - 09:56
еще многое зависит и от самой задачи, вот вы делаете решение гибким, поддерживающим множество СУбд, с мультиплатформенностью и т.д. А заказчику нужна просто приложуха с простеньким назначением. Зачем тратить кучу времени на создание такой гибкости, которой никто не воспользуется? Может это и не тру, но для узконаправленных проектов вполне нормальная практика такой привязки. Это экономит время разработки, а заказчику сумму работ.
   MadHead
 
27 - 27.10.21 - 10:04
(26) Применение так называемой чистой архитектуры оправдано для монолитных интерпрайз приложений. Иначе довольно рано наступит момент, что поддержка станет адом, если порезать приложение на сервисы/микросервисы, то такая архитектура позволяет применять простенькие архитектурные подходы и не париться. Но бизнес логика в БД - это слабый подход и в плане поддержки и в плане производительности
   Caber
 
28 - 27.10.21 - 10:15
Значит, реакт? У меня на очереди был ангулар, потому что на слуху часто всплывает. Здесь двое отметили, что реакт для бизнеса. Значит, реляционная база данных + реакт + бустрэп = само то?
   Конструктор1С
 
29 - 27.10.21 - 10:17
(25) от переноса логики с одного места в другое приложение меньше не становится. Если нужно тебе написать зубодробительный алгоритм расчета себестоимости, то он в любом случае будет зубодробительным. Мало того, когда идёт умышленное разбиение на слои, количество кода несколько увеличивается. Но эта жертва во имя облегчения жизни в будущем
   Конструктор1С
 
30 - 27.10.21 - 10:20
(26) принятие преждевременных решений тоже зло. Например, можно нашинковать сотню микросервисом, уграбливая кучу усилий на взаимодействие между ними. Всё во имя гипотетической возможности сложной децентрализации приложения. Но если децентрализации приложения так и не настанет, то все усилия окажутся мартышкиным трудом
 
 
   Kassern
 
31 - 27.10.21 - 10:21
(30) вот и я про это же. Надо здраво оценивать задачи и ее перспективы.
   Вася Теркин
 
32 - 27.10.21 - 10:22
(0) Ты бы ещё голосовой ввод к окошку прикрутил... А у 1С скоро так и будет. Говоришь "они опять продали эту кривую фигню и ту зеленую вчерашним дебилам за наличку." А тебе сразу накладные и эсф  и кассовый чек сами оформляются.
   Caber
 
33 - 27.10.21 - 10:32
(32) Ну вообще то, когда к нам на работу приходила важная шишка из чиновников, ее попросили сказать мнение о 1С. Она как раз и отметила, что очень удобная программа - мышкой наводишь, хочешь что то выбрать, а 1С сама уже подставляет то, о чем она подумала. Ей это очень понравилось и отложилось в памяти. 1С знает путь к сердцу женщин
   ДенисЧ
 
34 - 27.10.21 - 10:35
(33) А ещё там котик есть!
   Вася Теркин
 
35 - 27.10.21 - 10:41
(33) А с Украины не приходили? Белый цвет на синий поменять в такси?
   MyNick
 
36 - 27.10.21 - 12:21
(0) Я когда игрался, на vue делал. Там все просто. Связываешь элемент с данными, пишешь метод, забирающий эти данные с сервера, vue тебе сам все отрисует как надо.
Ну с простотой в 1С конечно не сравнить, но MVC - это те же яйца, только в профиль.


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.