Наверное, кому-то бы наличие аббревиатур и терминов облегчило понимание смысла, но кому-то нет. В начале статьи я упомянул о том, что материал для всех кругов разработчиков.
Да, есть есть несколько вариантов реализовать предметную область. Вероятно, существующую у нас систему можно охарактеризовать как Domain Model.
К тому же зачастую (моё мнение) сложно подогнать какую-то систему под одно описание, потому что в ней чего-то недостаёт, а что-то наоборот присутствует, чего нет в упоминаемом паттерно, методике. Поэтому я описал все просто и понятно словами.
Спрятать связь? Да, можно спрятать физическую связь, можно создать виртуальную. При этом сервер обладает возможностью анализировать эти связи и выдавать необходимые результаты на сложные запросы без явного указания, как именно эти связи строить. Основная фишка не в объектности, абстрактности, а именно в автоматической связываемости объектов. И это касается не только при запросах на чтение, но и на запись, например, постинг форм, в которых множество объектов содержит свои данные.
Эх, облажался немного, произошло недопонимание.
Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.
В достаточно мере верно сформулировано. Хотя добавить полной независимости от способа хранения не получится, точнее это можно реализовать, но существенной ценой.
Возможно. На что фантазии хватило. Ведь фишка в том, что для подсчета такой статистики, как вы это называли, обычному создателю проекта надо написать всего лишь одну несложную строчку. В ином случае кто-то мог бы написать один SQL-запрос. Я просто привел пример архитектуры в статейке, которая применима для довольно широкого круга задач.
Схема существует уже много лет, на ней работали проекты совершенно разной нагруженности. Сложности бывают, но ведь мы обсудили лишь часть общей системы. Есть другие части, которые в том числе нацелены на разгрузку мощностей сервера.
Основная концепция — что простые вещи можно делать простыми средствами. Если становится понятно, что абстракция мешает, то всегда можно реализовать функционал альтернативным способом (благо, MVC придерживаемся). Т.е. к объектному серверу можно обратиться не только через API, но и иными способами, при этом часть алгоритмов, заложенных в объектный сервер просто не буду использоваться. Кроме того, в самом объектном сервере заложены механизмы типа представлений, который иногда тоже позволяют делать хитрые вещи.
Конкретно вмешаться в запрос при обращении через описанные механизмы нельзя. Можно лишь понять, что данная выборка существенно мешает системе, переписав ее на другую, более простую, добавить индексы на нужные атрибуты (делается так же довольно абстрактно от БД).
Т.е. «черный ящик» для разработчика существует до тех пор, пока не возникают проблемы и ему не надо с ними разбираться. При этом средства для изучения проблем имеются.
Я бы назвал эту реализацию службой, слушающей определенный порт. ORM имеется и включен в сервер объектов. Задача ORM в данном случае по максимуму избавить веб-разработчика от мыслей о базе данных, зачастую человек вообще не знает, на какой СУБД работает проект. Лишь в особых случаях это приходится вспоминать.
Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
Не очень давно ушел с них, т.к. практически нулевой эффект был. Через некоторое время прислали пару, кажется, писем с вопросом, почему перестал пользоваться сервисом, у нас тут новые возможности и т.п.
Я об этом и написал, что никакие инструменты не помогут человеку, который просто незнаком с правилами.
Ну и никто не требует идеальности, хотя бы основные правила.
Истину глаголите.
А если для многих Айтишников ресурсы вроде Хабра являются единственными, что они читают кроме мануалов, то что с ними будет дальше, если каждый в своих сообщениях будет просто игнорировать запятые и доносить информацию в таком виде…
Ничего хорошего.
Нет, идеально не нужно. Но хотя бы самые обычные случаи употребления знаков препинания можно соблюдать. Хотя бы из-за уважения к другим, к русскому языку.
Поводом для поста было 2 сообщения за последних 2 дня, где с этим было очень плохо.
Я не критикую, всем этим людям я написал личные сообщения с объяснением ошибок. Просто так. Ну и тут поделился знаниями с остальными.
Время есть всегда.
Если ты можешь найти время на изучение языка, на котором ты общаешься с выч.техникой, то почему бы не найти чуть меньше времени на изучение языка, на котором ты общаешься с живыми людьми…
Да, есть есть несколько вариантов реализовать предметную область. Вероятно, существующую у нас систему можно охарактеризовать как Domain Model.
К тому же зачастую (моё мнение) сложно подогнать какую-то систему под одно описание, потому что в ней чего-то недостаёт, а что-то наоборот присутствует, чего нет в упоминаемом паттерно, методике. Поэтому я описал все просто и понятно словами.
Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.
Основная концепция — что простые вещи можно делать простыми средствами. Если становится понятно, что абстракция мешает, то всегда можно реализовать функционал альтернативным способом (благо, MVC придерживаемся). Т.е. к объектному серверу можно обратиться не только через API, но и иными способами, при этом часть алгоритмов, заложенных в объектный сервер просто не буду использоваться. Кроме того, в самом объектном сервере заложены механизмы типа представлений, который иногда тоже позволяют делать хитрые вещи.
Конкретно вмешаться в запрос при обращении через описанные механизмы нельзя. Можно лишь понять, что данная выборка существенно мешает системе, переписав ее на другую, более простую, добавить индексы на нужные атрибуты (делается так же довольно абстрактно от БД).
Т.е. «черный ящик» для разработчика существует до тех пор, пока не возникают проблемы и ему не надо с ними разбираться. При этом средства для изучения проблем имеются.
Ну и никто не требует идеальности, хотя бы основные правила.
А если для многих Айтишников ресурсы вроде Хабра являются единственными, что они читают кроме мануалов, то что с ними будет дальше, если каждый в своих сообщениях будет просто игнорировать запятые и доносить информацию в таком виде…
Ничего хорошего.
Поводом для поста было 2 сообщения за последних 2 дня, где с этим было очень плохо.
Я не критикую, всем этим людям я написал личные сообщения с объяснением ошибок. Просто так. Ну и тут поделился знаниями с остальными.
Если ты можешь найти время на изучение языка, на котором ты общаешься с выч.техникой, то почему бы не найти чуть меньше времени на изучение языка, на котором ты общаешься с живыми людьми…