Проектирование сущностей, сервисов и репозиториев

Обсуждаем, как правильно строить приложения
anton_z
Сообщения: 419
Зарегистрирован: 2017.01.15, 15:01

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение anton_z » 2019.08.17, 03:11

samdark писал(а):
2019.08.16, 20:58
Если вам будет его нехватать, то сделать его самому в index.php — проще простого.
Да это понятно. Но такое использование уже не будет общей практикой...

Аватара пользователя
samdark
Администратор
Сообщения: 9134
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение samdark » 2019.08.17, 14:05

Так мы и не хотим чтобы service locator был общей практикой.

sda
Сообщения: 332
Зарегистрирован: 2013.12.19, 09:29

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение sda » 2019.08.25, 16:15

uEhlO4a писал(а):
2019.08.15, 00:16
по поводу ACID и заказа за который не оплатили, то хочу сказать, что только благодаря ACID клиент смог его вообще сьесть
ACID не всегда работает. Представьте сайт бронирования путешествий. Необходимо забронировать билет на самолет, гостиницу и такси в рамках одного бизнес-процесса. Сделать атомарно такое невозможно. Используют Saga pattern. Большинство бизнес-процессов в нашем мире не атомарны и для людей это нормально, соответственно нормально и для модели бизнес-процесса.
uEhlO4a писал(а):
2019.08.15, 00:16
NoSQL треш вроде сдулся, или не совсем? Я не особо за этим слежу просто.
Не сдулся. Для распределенных систем не работает ACID и JOIN из классических для PHP рсубд. Убираем это и остается объектно-реляционное несоответствие и ноль преимуществ. Используют потому что так учат книги/курсы, а по другому не умеют/не знают.

uEhlO4a
Сообщения: 57
Зарегистрирован: 2017.08.12, 19:19

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение uEhlO4a » 2019.08.28, 12:46

По тому что вижу, этот "Saga" https://blog.couchbase.com/saga-pattern ... ices-part/ это https://martinfowler.com/eaaDev/EventSourcing.html которое доказало свою нереальную сложность, по крайней мере в моей практике я таким не страдаю. Также ты наверно не до конца понимаешь, что такое "распределение". В этой Saga есть понятие "centralized service", по сути какая-то одна штука которая все равно будет ОДНА и будет разруливать то, что делает база данных, только в Х-раз дольше из-за криворукости + теряется целостность, т.к. событие уходит в очередь - когда очередь переполняется то тот бизнес сложит лапки.

Если нужны кластеры данных - для этого есть кластеры данных. Понимаешь? Пример https://www.mysql.com/products/cluster/
в отличии от текущего состояния ИТ сферы, раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль

Насчет ACID - это Atomicity, Consistency, Isolation, Durability
Существует примерно 4 уровня изоляции. Есть разный подход репликаций и т.д.
ACID никаким боком не относится к NoSQL. Это 2 разные технологии. Они не взаимоисключающие. https://docs.mongodb.com/manual/core/transactions/


Но я не спорю, для дерьма вроде твитера или фейсбука, где потеря тупых комментариев ничего не означает, можно и блокнот использовать с побитовым чтением.
вот примерный разбор twitter https://www.8bitmen.com/what-database-d ... deep-dive/
как видишь, для хранения денег и твоих персональных данных (которые они потом продадут) используется MySQL, а для всякого пользовательского дерьма - всё что только угодно, т.к. это не имеет никакой ценности (к слову, в MySQL можно отключать изоляцию, врубить кеш на 90% памяти и будет та же тема, только минус будет в размере запроса и JOIN, потому и используют подход с хеш-ключами, т.к. это проще для разработчика и для сети)

Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям


п.с.
в общем, моя твоя не понимать. Давай пример, где ты используешь "Saga pattern" - сколько миллионов пользователей/заходов и т.д.? Или ты на 1.5 инвалидах это применяешь? Я с сайтами до 100к пользователей работаю, чтобы понятней было

п.п.с.
https://nickcraver.com/blog/2016/02/17/ ... 6-edition/

Аватара пользователя
ElisDN
Сообщения: 5357
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение ElisDN » 2019.08.28, 19:00

uEhlO4a писал(а):
2019.08.28, 12:46
раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль... Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям
Можно и обратное сказать. Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специально для них придуманные и оптимизированные табличные, key-value, документные, графовые, объектные, поисковые и колоночные БД. И только "одноклеточные" SQL-щики на всё готовы, чтоб только из мантры "транзакции ис каропки" во все места впихнуть SQL и выгребают обходы графов. Та же печаль, только в профиль.

uEhlO4a
Сообщения: 57
Зарегистрирован: 2017.08.12, 19:19

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение uEhlO4a » 2019.08.28, 19:44

ElisDN,
ха-ха. твои аргументы норм работают при разводе недалеких людей псевдокурсами, но вот в реальном мире всё совсем по-другому.
Это твое "Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специальн.." вообще что-то непонятное. Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных, и если в какой-то момент один с хипстеров занес им FlockDB , то он с такой же скоростью оттуда и уехал. Это чтобы ты понимал https://github.com/twitter-archive/flockdb

"обходы графов", ха-ха. жги еще!

uEhlO4a
Сообщения: 57
Зарегистрирован: 2017.08.12, 19:19

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение uEhlO4a » 2019.08.28, 19:54

кстати,
1. поисковых бд нет - есть поисковые движки, можешь почитать https://www.elastic.co/products/elasticsearch - они даже так и пишут ENGINE
2. колоночные бд - это сам придумал или кто подсказал? (п.с. а, вижу, есть ClickHouse , какая-то фигня от яндекса https://github.com/yandex/ClickHouse)
3. обьектные бд, key-value и остальной треш - это одно и тоже noSQL, то есть без конкретной схемы для данных, по сути BLOB . И они все одинаковы впринципе, за исключением поддержки транзакций и типов репликаций. ха-ха

аминь

Аватара пользователя
ElisDN
Сообщения: 5357
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение ElisDN » 2019.08.29, 00:09

uEhlO4a писал(а):
2019.08.28, 19:44
Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных...

"обходы графов", ха-ха. жги еще!
Понятно. Больше вопросов не имею :)

Аватара пользователя
samdark
Администратор
Сообщения: 9134
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение samdark » 2019.08.29, 10:11

Ну вот... получилась ещё одна монстротема обо всём и сразу с холиваром. Прикрываю. Давайте общаться более сфокусировано.

Закрыто