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

[fixxxer]

User - value object,

В ЖО. Чистый value object - это ерундистика полная, получается, что все вокруг должны знать о его полях. Это вообще антиООП, вся "инкапсуляция" мехом наружу.

 

[MiksIr]

вот еще "в кассу" из моей жизни: добавим в данные пользователей поле paid bool, и архитектура приложения вырастает из фиксеровского примера на 3 строки в конструкцию с выделением большого слоя REST с реализацией failover и переводом сервера B в специальный режим ограниченного функционала при сбое связи

Как это _нарушит_ его архитектуру? Расширит - ок, нарушит ли? Этот faillover будет или в слое коннектора или как обертка по эксепшену.
И к слову о 50мб - ну переделали на csv, ну меняем слой вывода, раньше он плевался в REST/SOAP, щас в файл. Изменилась архитектура принципиально?

 

[MiksIr]

Я об ином подходе. Есть User extends ItemEntity, есть UserCollection extends EntitiesCollection<User> (дженерик эмулируем статическим методом getItemClass). Item умеет себя загрузить и сохранить через датасорс, Collection умеет делать запросы к датасорсу на много итемов и создавать их коллекцию. Да, получается связанная пара, но не вижу в этом ничего плохого: Collection это такая загружалка-и-фабрика, но Item можно использовать и отдельно (так же как объект можно создать фабрикой, а можно просто так).

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

 

[grigori]

сам коннектор раздувается на 3 слоя, а этот failover делается в отдельном сервисном слое между коннектором и контроллером

>Изменилась архитектура принципиально?
ты че, не выспался? весь REST API вообще выкинули, все заново написали, вместо обработки входящих запросов забирают curl-ом файл и парсят его по крону

 

[MiksIr]

сам коннектор раздувается на 3 слоя, а этот failover делается в отдельном сервисном слое между коннектором и контроллером

>Изменилась архитектура принципиально?
ты че, не выспался? весь REST API вообще выкинули, все заново написали, вместо обработки входящих запросов забирают curl-ом файл и парсят его по крону

@grigori и что? Архитектура - это не название классов, это разделение по обязанностям. С тем, что бы при изменении ситуации достаточно было заменить какую-то часть. Замена REST API - в худшем случае замена RestConnector на FileConnector и модификация User, в лучшем - только первое. Зависит от интерфейса коннектора. Это я про генератор, т.е. с вашей стороны. С их стороны - в общем то же самое - меняется слой коннектора, который забирает файл курлом и читает его.
Ну вот, зато я теперь вижу, что коннектор должен быть более абстрактен, т.е. не post/get, а get/getAll/add, спасибо.

 

[grigori]

молодец, умный тролль, я отписываюсь от темы

 

[MiksIr]

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

Совсем чуть-чуть сложнее, как раз, что бы чуть-чуть выдумать )))

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

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

 

[Тугай]

fixxxer, не совсем так.

Cледуя Фаулеру и перведя все его паттерны получим:
connector - gateway, collection - "table data gateway", user - "row data gateway".
И collection и user - используют один value object скажем UserData - инкапсуляция за счет композиции, а не наследования.

То, что connector инжектится и в collection и в user - это нормально, мы можем добавить пользователя (value object UserData) и из коллекции и usera (row data gateway объекта).

MiksIr, следуя тому же Фаулеру, объект user - "row data gateway", может первратится в active record, тогда когда, нам понадобится, например, функция формирования ФИО из трех составляющих полей или скажем вычисление возраста по дате рождения, и т.п.

connector - может выполнять роль дата мапера и мапить данные из api на value object.

Не договорившись о терминологии заниматься теретическими построениями затруднительно.
Да и паттерны Фаулера - это консультативные услуги, а не наука.
(Что-то вроде справочника по ботанике, где по внешним признакам мы пытаемся определить вид растения(паттерн))

 

[MiksIr]

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

Отлично, спасибо. Мне как раз теории не хватает, а времени погружаться в книги нет =(