Суббота, 18.05.2024
Мой сайт
Меню сайта
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0
Главная » 2019 » Февраль » 7 » Технология MVC
21:05
Технология MVC

Технология MVC

Это инструмент написания клиентских приложений для баз дынных. Клиентское приложение выбирает, добавляет, корректирует и удаляет строки каких-то таблиц этих баз данных. Клиентов этих можно писать много на чём.
Плюс Интернет – клиента – отсутствие необходимости что-то ставить на машине пользователя и менять при изменении программы. Один из довольно существенных минусов – трудоёмкость написания (в сравнении, например, с разнообразными средами разработчика). Если в 1С каком-нибудь добавить справочник и полный инструментарий ввода информации можно за минуты, то новый экран ввода информации в Web-приложении рисуется за полдня (если очень надо очень быстро). Т.е этот вариант программирования остаётся долгим и трудоёмким процессом.
Этой технологией пытались, по моим ощущениям, справиться с этой проблемой.
Осторожно напишу, что, похоже, справились. Принципиально новых механизмов работы именно с Интернетом там не появилось. Он всё так же при каждом действии гонит пользователю всю корректируемую информацию страницы. Но добавлены стандартные инструменты, всё-таки упрощающие работу.
Появился, например, стандартный элемент – разбивка по страницам:

В своё время именно его мне надо было написать чтобы считать продукт хотя бы условно работающим, но не хватило уже сил и энтузиазма. Написать всё можно, но почему мне такое, совершенно необходимо, надо писать? Вот теперь это есть в стандартном наборе.
Все вместе оставляет ощущение возврата в прошлое. Это не плохо, а интересно. Во-первых для формирования интернетовских страниц взята технология описная тут:
http://akostina76.ucoz.ru/blog/2016-09-20-3449

Другое дело, что они облагородили результат и страница не перерисовывается полностью, т.е нет мелькания экрана. Функции и переменные, конечно, называются иначе, но метод  прямой работы с отправкой данных именно тот.
Во-вторых, при работе с таблицами сделано решительно всё чтобы можно было программировать, но не писать и не видеть SQL-строки. С одной стороны это забавно потому что последние 20 лет этот метод считался не рекомендуемым. С другой – во всё тех же средах разработчика были оставлены методы работы похожие на то как работали в DOS-е. Те кто 20 лет тихо сопротивлялся SQL строкам могут праздновать своеобразную победу. Здесь основной метод больше похож на работу с DBF файлами чем на работу с таблицами базы данных.
Ничего плохого в этом нет. Просто машина генерирует SQL-строки сама по тому что написано программистом без этих строк. Так  что это просто проникновение методов сред разработчика в традиционное программирование.
Основное что делают все это среды разработчика сами – это корректируют информацию. Программист избавлен от этой работы. Но чтобы переложить всё это на внутренние механизмы машины потребовалось подробное описание базы данных, с которой надо работать.
Для хранения информации о таблицах используются текстовые файлы – модули:

Здесь у меня созданы описания таблиц лицевых счетов (K_LS), названий юридических лиц (K_UL) и… учреждений (K_UL_K_UL). Последняя таблица существует отдельно, потому что названия могут меняться и т.д.
Обычное для базы хранение разной информации в разных таблицах означает что чтобы получить всё нужные мне надо связать таблицы по идентификаторам и повытаскивать отовсюду информацию:

Но, во-первых, я не хочу писать SQL-строки. Во-вторых, даже если я это вытащу, а не смогу эту информацию откорректировать. Требуется чтобы машина сама написала SQL-строку, которая всё это собирает и чтобы она же сама (почти сама))) ) всё это изменяла.
Описание простого справочника лицевых счетов:

Тут нет ничего особо интересного. Просто механизму MVC сообщается, что в таблице K_LS есть два поля, с которыми надо работать. Это числовой идентификатор K_LSID и строковый номер счета CLS. На просмотр этого справочника надо вытаскивать эти поля. При корректировке будут корректироваться они же.
А вот список учреждений интереснее:

В нем появляются так называемые виртуальные поля с информацией из связанных справочников.
Вся эта информация описаний таблиц и связей между ними позволяет по такой информации:

… генерировать SQL-строку. Вот чего он нагенерировал:


Это всё так страшно выгладит потому что он (сам же) добавил сюда разбивку по страницам. Важно же то, что он сам добавил связи с другими таблицами (причём нужного типа).
Выражение выше явно проще SQL-строки так что механизм явно можно считать удобным упрощением работы… Причём вполне работающим.  
Корректировать данные таблиц по таким описаниям он тоже может. «Почти сам» означает что поля ему, всё-таки, надо вытащить на местный аналог формы для корректировки информации. Но для сохранения достаточно написать нечто типа «db.Save» и он сам всё сделает как делают всё те же среды разработчика. Очень удобно, что можно ему подсунуть для корректировки и хранимые процедуры. В некоторых случаях это очень важно.
Годно. Но вторая общая проблема Интернет –страниц никуда не делась. Здесь у меня сделано ограничение списка:

… потому что если его нет, то он при каждом действии будет гнать клиенту не такой короткий список с «прим»:

… а полный список распорядителей, которые есть в базе (а их много).
В Access-е каком-нибудь меня этот вопрос не интересует:

… потому что все эти списки загружаются один раз при открытии формы. При нажатии кнопки «Поиск» запрашивается только список выборки.
Везде есть свои плюсы и минусы.
p/s
Наверное, надо пояснить почему настойчиво рекомендовались SQL-строки. Потому что рекомендовались даже не они, а хранимые процедуры, вызываемые с параметрами. Вот то большое и длинное, что было показано выше, надо не на ходу генерировать а записать в хранимую процедуры и вызывать. Хранимые процедуры работают быстрее потому что серверу не надо разбирать текст. И потому что для созданных процедур у него уже собран некий внутренней скомпилированный для выборки информации код. 
Процедуры из MVC-приложения можно вызывать. Новый инструментарий просто добавляет возможности.

p/p/s
Если в районе 2000-го года произошла победа интерпретаторов над компиляторами (потому что так удобнее и мощная техника это уже позволяла), то наблюдаемое похоже на победу сред разработчика над привычным программированием. Строго говоря, это менее качественно, но техника уже тоже позволяет.

Просмотров: 209 | Добавил: akostina76 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Форма входа
Поиск
Календарь
«  Февраль 2019  »
ПнВтСрЧтПтСбВс
    123
45678910
11121314151617
18192021222324
25262728
Архив записей
Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Copyright MyCorp © 2024
    Бесплатный конструктор сайтов - uCoz