Задачка на архитектуру

[AmdY]

@cDLEON прав, задача интересна только в теории, в реальности же, лучше делать любым способом подходящим под требования, наплевав на зависимости, solid, думая лишь о YAGNY, когда проблема на проекте встречается во второй раз, тогда уже можно думать и рефакторить.

 

[cDLEON]

@AmdY да дело даже не в этом!
Здесь задача про архитектуру, в которой не описывается фундамент. Это тоже самое, что строить мост между двумя точками, высота\материал и прочие элементы фундамента которых не заданы.

 

[fixxxer]

Возможно, потом сделаю из это задачи тест на собеседовании.

На собеседовании, вот в такой постановке, правильный ответ: конкретизируй задачу, если нужен общий ответ - он прост: сделаю так, как проще и быстрее в конкретном случае.

Архитектурных астронавтов на йух, работать кто будет?

Согласен с AmdY что для одного неповторяющегося кейса надо просто взять и насрать в контроллере. Когда понадобится второй раз - тогда берем и уносим в сервис или модели, причем видя что реально надо абстрагировать, а не выдумывая заранее.

 

[Вурдалак]

Ну просто вы написали пример кодом, а по коду совсем не ясно, где этот User используется.

То же самое, что у @AmdY, только в красивой обёртке, если хочешь. Но суть в том, что ты этот репозиторий на фейковый можешь заменить и прописать это в конфиге окружения верстальщика, ему не нужно будет настраивать ничего, а данные для вёрстки из контроллера приходить будут.

Синхронизация вызывает вопросы, потому что если у тебя есть логика, по которой можешь определить в каком из сервисов искать пользователя, то зачем тогда синхронизация нужна? В противном случае, это, по-моему, проблемы этих двух сервисов.

 

[MiksIr]

Мда... Хорошо еще не спросили "а на каком фреймворке".
Да чего уж, берем run.php и пишем: curl_init; curl_exec; foreach; curl_init; curl_exec. Чем не вариант, а?

cDLEON, а что, вас правда таймауты ожидания, поведение при "все отвалится" и "ожидаемая нагрузка" могут сильно изменить архитектуру. "Хуяк-хуяк", да, а потом думаем куда соломки подстелить? Удобно, жаль что на своей работе не могу позволить такого.

На собеседовании, вот в такой постановке, правильный ответ: конкретизируй задачу, если нужен общий ответ - он прост: сделаю так, как проще и быстрее в конкретном случае.

Архитектурных астронавтов на йух, работать кто будет?

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

А что бы понять, как на практике - это будет другая, практическая задача.

 

[hell0w0rd]

@MiksIr А чем мой вариант не вариант? зачем какие-то AR обертки?

 

[fixxxer]

Чтобы ставить теоретические задачи, надо уметь хорошо описывать модель. Заметь - тебя почти никто с первого раза не понял. Я вот тоже не уверен, что правильно понял, но если понял, то чего уж там, втупую:

$UserCollectionA = (new UserCollection)->setDatasource($ConnectorA)->loadAll();
$UserCollectionB = (new UserCollection)->setDatasource($ConnectorB)->loadAll();
$UserCollectionB->diffWith($UserCollectionA)->each(function(User $User) { $User->add(); });

Это если рест тупой донельзя. Если можно отсортировать по ключу, по которому делаем сравнение, и умеем читать поток, можно сделать элегантнее на лету.

 

[grigori]

первое, о чем я подумал - обеспечение целостности
мы 2 года писали распределенные системы, свои API и интеграции с чужими, и вопрос вроде

а что, вас правда таймауты ожидания, поведение при "все отвалится" и "ожидаемая нагрузка" могут сильно изменить архитектуру.

ставит меня в тупик

это может говорить только человек, который никогда не поддерживал интеграцию с синхронизацией состояний

 

[MiksIr]

но если понял, то чего уж там, втупую

Угу, что-то такое и ожидал изначально, спасибо. Единственное, в этом случае получается, что с datasource связаны и c UserCollection и c User (что бы делать add()), вот это мне не очень нравится.

 

[MiksIr]

первое, о чем я подумал - обеспечение целостности
мы 2 года писали распределенные системы, свои API и интеграции с чужими, и вопрос вроде
это может говорить только человек, который никогда не поддерживал интеграцию с синхронизацией состояний

Ну вот берем пример fixxer-а и с удовольствием послушаю, какое тут должно быть обеспечение целостности и как он принципиально меняет написанную архитектуру.

 

[MiksIr]

@MiksIr А чем мой вариант не вариант? зачем какие-то AR обертки?

Да варианта то особо не было. Кто будет брать данные из сервиса и создавать объекты? Кто будет синхронизировать. Кто будет добавлять. В этом вопросы то.

 

[grigori]

Ну вот берем пример fixxer-а и с удовольствием послушаю, какое тут должно быть обеспечение целостности и как он принципиально меняет написанную архитектуру.

я правильно понимаю, что ты предлагаешь мне взять чужой код и на его примере развлечь тебя историей про обеспечении целостности из моего опыта?
ты ничего не напутал?

 

[MiksIr]

ты предлагаешь мне взять чужой пример и развлечь тебя историей про обеспечении целостности? ты ничего не напутал?

Нет, все точно. Считается, что сказав А следует говорить Б. Ну если человек - профессионал, конечно.

 

[grigori]

если человек - профессиональный инженер, он будет использовать инженерный подход с примерами из личного опыта, а не развлекать праздношатающихся ответами на вопросы в стиле "есть ли жизнь на Марсе"

я могу что-то показать с кодом из личной практики, относительно кода фиксера вопросы к фиксеру

 

[fixxxer]

Угу, что-то такое и ожидал изначально, спасибо. Единственное, в этом случае получается, что с datasource связаны и c UserCollection и c User (что бы делать add()), вот это мне не очень нравится.

Я считаю нормальным, что коллекция содержит фабричный метод для item-а коллекции и при создании item-ов инициализирует их своими настройками и зависимостями. Собственно так себя фабрика и должна вести.

Впрочем, если не нравится, тоже не вижу проблем:

$UserCollectionB->diffWith($UserCollectionA)->each(
   function(User $User) use ($ConnectorB) { $User->setDatasource($ConnectorB)->add(); }
);

Касаемо целостности - а как можно ее нарушить, добавляя по одному пользователю, никак не связанному с другими? Отвалилось - запускаем заново и все. Вроде так задача стоит.

Если надо трекать изменения, то все равно же тут синхронизация в одну сторону, этакий мастер-слейв, все решается версионированием юзеров. Вот если в обе стороны, то да, начинается веселуха по полной =)

 

[MiksIr]

Я считаю нормальным, что коллекция содержит фабричный метод для item-а коллекции и при создании item-ов инициализирует их своими настройками и зависимостями. Собственно так себя фабрика и должна вести.

Меня скорее не это напрягает, а то, что про коннектор должны знать две сущности - и коллекция и сам юзер. Появляется лишняя связанность. Может добавлять должна тоже коллекция? Тогда из коллекции у нас получается что-то вроде датамапера.

 

[cDLEON]

@MiksIr во-первых - я не предлагал делать "хуяк-хуяк". Я, как раз таки, предлагал разобраться. Во-вторых, с данной постановкой задачи максиммум, что можно предложить - это хуяк-хуяк.
Вариантов синхронизации огромное множество. Но без деталей предлагать что-нибудь - тыкать пальцем в небо.
Ну а если в этом вопросе вас интересовало как объектики назвать, да какой объектик в какой завернуть, то это не архитектура - это словоблудие.
PS. Юзеру то конектор зачем сдался? $collectionB->add($user);

 

[grigori]

Меня скорее не это напрягает, а то, что про коннектор должны знать две сущности - и коллекция и сам юзер. Появляется лишняя связанность. Может добавлять должна тоже коллекция? Тогда из коллекции у нас получается что-то вроде датамапера.

у юзера нет зависимости от коннектора, только у коллекции, и датамаппера здесь тоже не надо

 

[MiksIr]

Знаете, есть люди - чистые практики. Они учились на практике, мыслят практикой и абстрактные задачи их ввергают в некий ступор (если, конечно, в этом дело, а не банальном ЧСВ). Бывают - чистые теоретики. Они бредят патернами, "олимпиадными" задачками и т.п. Надеюсь, что большинство все же - золотая середина, изучающая теорию для последующего применения на практике. Мне кажется, если бы вы выбирали врача - то вам бы не понравились первые два случая, ага.
Так вот, в данном случае я пытаюсь проработать теорию на абстрактной задаче. Если в ней что-то неясно, можно довыдумать. У @fixxxer ее решение не составило проблем, когда он отринул практику.
Потом эта теоретическая задача будет применяться на практике и рефакториться, если новые вводные конфликтуют со сделанной архитектурой. Но не буду делать это тут. Я ценю этот форум за людей с хорошей теорией и за практиков, способных помочь с конкретным затыком, на который гугл не ответит, но я еще не сошел с ума решать тут практическую задачу. Так что не нужно накручивать больше, чем есть.
Хотя если вы с этой позиции сможете растолковать, как заданные вами практические вопросы смогут полностью перевернуть изначальную архитектуру, хотя бы на примере кода @fixxxer - велкам. @grigori не захотел это делать
Классический пятнично-воскресный срач прошел вяло, но все же прошел, спасибо.

 

[MiksIr]

у юзера нет зависимости от коннектора, только у коллекции

У @fixxxer была - там юзер знал, как себя добавить. Мое первое решение было аналогичное - юзер знает как достать себя и как добавить. Т.е. аналогично SQL коду в модели. Не скажу, что очень понравилось мне это решение - по-этому стал думать дальше. А из известных мне патернов тут всплывает датамапер только.