Основные операции работы с данными
21.02.2016
|
velkin
 |
Structured Query Language — «язык структурированных запросов»
Не так много операторов, но их хватает для работы с данными. Остальное предназначено для другого. С другой стороны REST, вроде иное назначение, но основные принципы казалось бы те же самые.операторы манипуляции данными (Data Manipulation Language, DML):
SELECT выбирает данные, удовлетворяющие заданным условиям,
INSERT добавляет новые данные,
UPDATE изменяет существующие данные,
DELETE удаляет данные;
Representational State Transfer — «передача состояния представления»
Хотя данная концепция лежит в самой основе Всемирной паутины, термин REST был введён Роем Филдингом (англ. Roy Fielding), одним из создателей протокола HTTP, лишь в 2000 году. В своей диссертации «Архитектурные Стили и Дизайн Сетевых Программных Архитектур» («Architectural Styles and the Design of Network-based Software Architectures»)в Калифорнийском университете в Ирвайне он подвёл теоретическую основу под метод взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей репрезентативного состояния».
А можно ещё почитать "Архитектура корпоративных программных приложений" Мартина Фаулера.
CRUD: Create, Read, Update, Delete — «создание, чтение, обновление, удаление»
Operation SQL HTTP DDS
Create INSERT PUT / POST write
Read (Retrieve) SELECT GET read / take
Update (Modify) UPDATE POST / PUT / PATCH write
Delete (Destroy) DELETE DELETE dispose
Представлять Data Distribution Service думаю нет особого смысла. Кто увлекается поделиями OMG, тот скорее всего так же знает, про CORBA, UML и прочие, а кто не знает, тому и не надо.
Есть ещё Design Patterns, это уж так добавил в общем плане, где шаблон проектирование Свойство (Property) представлен составляющими Accessor и Mutator, а конструктор и деструктор за компанию, чтобы забить место. И конечно, С++, операторы new, delete и методы реализующие get, set.
Ниже приведён рисунок сопоставления, набросал на скорую руку, что вспомнилось, может не совсем верно, но не суть. Важно, что многие люди пришли к одной и той же идее. Для простоты буду называть её CRUD, так как образцы проектирования (design patterns) одновременно обо всём и ни о чём.
| рисунок 1. Сопоставление операция с данными в стиле CRUD | |
 | |
И вот вопрос, приходилось ли вам применять этот принцип на практике. Возможно в каком-то более сложном виде как у того же Мартина Фаулера в модели предметной области. Или может быть кто-то считает, что четырёх методов недостаточно, и лучше использовать что-то другое, на вскидку XML-RPC, CORBA, а то и вовсе какое-нибудь МЫЛО. Речь может быть так же об уровнях, слоях и прочих абстрактных прослойках.
| уровни и слои | |
 | |
Можно так же прокомментировать в стиле, "ерунда это всё, только зря время от просмотра котиков отнимает":
Встречает мастер своего преподавателя по вышке лет через восемь после
окончания вуза, разговорились, вспомнили время былое. Профессор
спрашивает:
— Вот я вам читал три года высшую математику, скажи, в жизни тебе мои
знания когда-нибудь пригодились?
Студент, подумав:
— А ведь был один случай.
— Очень интересно, расскажите, я его буду на лекциях рассказывать, что
высшая математика не такая абстрактная наука и в жизни бывает нужна.
— Шел я как-то по улице, и мне шляпу ветром в лужу сдуло. Так я взял
кусок проволоки, загнул его в форме интеграла и шляпу достал!
| 21.02.2016 4 комментария |
V>И вот вопрос, приходилось ли вам применять этот принцип на практике. Возможно в каком-то более сложном виде как у того же Мартина Фаулера в модели предметной области. Или может быть кто-то считает, что четырёх методов недостаточно, и лучше использовать что-то другое, на вскидку XML-RPC, CORBA, а то и вовсе какое-нибудь МЫЛО. Речь может быть так же об уровнях, слоях и прочих абстрактных прослойках.
мне вот кажется, что во всех этих схемах работа ведётся с каким-то статичным состоянием. и вот это вызывает непонимание.
а что же с пересылкой данных, обновлением состояния, которое уже изменилось в хранилище, или с несколькими источниками, которые влияют на одну сущность? не теряется ли здесь что-то важное?
F>а что же с пересылкой данных, обновлением состояния, которое уже изменилось в хранилище, или с несколькими источниками, которые влияют на одну сущность? не теряется ли здесь что-то важное?
Если взять реляционные базы данных, особенно клиент-серверные, то увидим множество решений подобных проблем разнообразными способами. Но самое интересное Data Manipulation Language с его SELECT, INSERT, UPDATE и DELETE продолжает существовать как ни в чём не бывало. В реальной системе нужно будет выбрать способ организации конкурентного доступа к ресурсу, но CRUD это не отменяет, просто меняется реакция на эти команды. Я как бы основательно подзабыл эту тему, там и роли, и права доступа, и что делать при обращении к ресурсу, то есть блокировать, не блокировать и так далее.
V>Задумался над операциями с данными. Для начала взять SQL с его DML.
Смешались в кучу конелюди, без обид
Вы умещаете в один пост язык запросов, протокол, подход к построению stateless-софта и опилки от Фаулера и надеетесь, что вам что-то полезное из этого сумбура выведут?
Напомню, этот раздел форума для практически применимых вопросов, для потрындеть — вэлкам в Философию ПО
V>рисунок 1. Сопоставление операция с данными в стиле CRUD
Классификация Борхеса
V>Можно так же прокомментировать в стиле, "ерунда это всё, только зря время от просмотра котиков отнимает"
В общем, попробуйте сами для себя объяснить, в чём пойнт поста.
С учётом очевидного факта: комплексные задачи решаются тоже комплексно, на разных уровнях, с разделением задачи на отдельные части и с их изоляцией.
Если использовать любой другой подход, то получается только заготовка для буллшит бинго, что собственно и
Ещё раз без обид, если взял слишком резкий тон — мои извинения
Вот как-то так.
S>Здравствуйте, velkin, Вы писали:
S>Вы умещаете в один пост язык запросов, протокол, подход к построению stateless-софта и опилки от Фаулера и надеетесь, что вам что-то полезное из этого сумбура выведут?
S>Напомню, этот раздел форума для практически применимых вопросов, для потрындеть — вэлкам в Философию ПО
Это и есть практический подход, причём смешались только родственные подходы, а XML-RPC, CORBA, SOAP и прочие остались за кадром, что так же отметил. Хотите конкретики, пожалуйста. Создаём по правилам метаобъектной системы Qt интерфейс ICrud. Можно так же создать класс AbstractCrud, что несколько иное, но это просто умозрительные эксперименты.
Далее наследуем от этого классы операций, причём вторая часть наследования может быть как раз для работы конкретно с текущей операцией. В общем множественное наследование с одним потомком QObject или какой-то иной подход. Далее видим, что можно подключаться к источникам данных вот так QNetworkAccessManager, в нашем случае в стиле REST, чтобы не переизобретать велосипед у которого вся разница в названии. Или подключиться к базе данных, а потом использовать её в стиле CRUD.
К тому же в Qt можно работать с различными базами данных одинаковым образом. Чисто для примера QSqlTableModel, этот класс так же можно отнести к паттернам проектирования. Немного теории, оставим пока уровни (или ярусы), то есть клиент-сервер, сосредоточимся на слоях:
Если бы нужно было реализовать удалённый вызов процедур (XML-RPC, CORBA, SOAP), то в Qt теряло бы всякий смысл выдумывать что-то новое, так как метаобъектная система имеет отличную поддержку интроспекции.
И не важно как она реализована, пусть даже и на свитчах, а сигнатуры методов это нормализованные строки, главное что она есть. Следовательно прикручивать различные техники удалённого вызова процедур можно в отдельных классах. Хотя есть ещё тема интерфейсов, именно так реализована поддержка плагинов, и на мой взгляд в сочетании с другими возможностями метаобъектной системы это не менее мощный механизм передачи функциональности.
Тоже самое касается баз данных, да можно говорить о шлюзе записи данных, (Row Data Gateway), шлюзе таблицы данных (Table Data Gateway), и так далее и тому подобное, но с практической точки зрения это лишено смысла, по банальной причине, как и интроспекция это всё уже реализовано в QtSql. Хочешь подключайся к SQLite, хочешь к Postgres, или мною не любимый MySQL, а так же к другим базам данных.
В первом сообщении рассматривались источники данных, причём особенно подчёркиваю, что никакие кони там не смешались, создав слой абстракции можно на практике работать со всеми решениями одинаково.
Что касается домена (бизнес логики), то по Мартину Фаулеру имеем:
Помимо "Архитектура корпоративных программных приложений" у него есть ещё несколько книг, одна из них "UML Основы. Краткое руководство по унифицированному языку моделирования". Потому не буду изобретать новые слова, и стану писать названия как есть.
Первый вариант модуль таблицы, реализовать проще всего, в последнем случае модель предметной области при многократном возрастании сложности будет проще поддерживать. Здесь и далее буду говорить о бизнес логике как о модели предметной области.
Давайте порассуждаем. Предположим в бизнес-логике выделяется ресурс, у него по CRUD будет 4 операции. Плюс создаём прослойку для обращения к источникам данных. Всегда и везде используется CRUD, а каким образом работать с данными решает сам источник. Использует ли он их из какой-либо базы данных, или с xml файла на диске, или через REST, по HTTP.
Так же не имеет значения через какой транспортный протокол всё это проходит, например, не через HTTP, а через XMPP или всё, что угодно. Детали реализации скрыты посредством CRUD. Формат данных в данном случае тоже не играет особой роли, в представление может уходить один, в источниках данных для передачи использоваться другой.
Опять же не нужно зацикливаться на Qt, можно порассуждать о других библиотеках и языках, PHP, Java и тому подобное. Я считаю, что архитектура не должна зависеть от конкретного языка программирования, и может лишь ограничиваться им, то есть если нельзя реализовать эту архитектуру, то можно взять другую, а не изменять эту архитектуру выдавая за старую.
S>Напомню, этот раздел форума для практически применимых вопросов, для потрындеть — вэлкам в Философию ПО
С философией, имею в виду топики, которые появляются в том разделе у данной темы нет ничего общего. Мне близки разделы "Архитектура программного обеспечения", "Управление проектами" и "Qt". Если уж помещаю тему в эти разделы, то не просто так. Впрочем уже написал, что можно отвечать в стиле "не мешайте мне рассматривать котиков".