А если объект с джсоном просто в конце выдать в тот же output и будет воид

Думал...но тоже как то костыльно уже касаемо спринга. Мне его надо самому в json конвертнуть и записать в респонс как строку. И тогда я могу вынести общий инрфейс типа presenter.present(). Войдовский.

Там ещё екселевский отчёт сильно отличается, в нем 2 доп страницы и ТД. Вот если бы отчёт был на 100строк, то я бы мог его данные сначало вытащить, а потом передать в презентер и он бы уже строил что нужно. А тут курсор, я итерируюсь и одновременно строю отчёт и сразу пишу его в аутпутстрим. И для каждого формата, поразному

Пока что приходится дублировать цикл с алгоритмом для каждого формата. И единой ответственностью там не пахнет

что общего в этом коде?

цикл по заказам? можно вынести его отдельно, если требуется, сделать класс, который имеет интерфейс "обработать один заказ", и передавать в этот класс каждый заказ в цикле, а сам интерфейс 3мя способами будет реализован

т.е. там условно AbstractReportBuilder {
 createNewReport();
 addOrderToReport(Order order);
 finishReportCreation();
}
первый метод вызывается в начале, потом в цикле вызывается метод добавления заказа в отчет, и когда все закончилось - метод завершения посторения отчета, который записывает собранный контент куда надо, либо, если контент сразу пишется в стрим / сокет, просто закрывает его, или еще что-то в этом роде.

Сразу видно синьер архитектор

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

можно зайти с другой стороны, сделать генератор, который будет требовать некий OrdersProvider {getNextOrder()}

хотя вроде у него так и сделано

Идея нормальная. В некую сущность передавать интерфейс билдер и дергать его методы. Немного криво будет в одном моменте. Например сделаю interface OrdersReportBuilder{
void createHeader();
void createRow();
void createFoiter();
}

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

ничего не делай, пустые методы

Ну сводится к стратегии все. Надо подумать. Я пробовал, но что-то там не зашло не помню что

Точнее нет, туплю, шаблонный метод

Интересны ваши мысли касаемо следующего дебата.
По сути, большая часть MVCшных (и не только) приложений являются процедурными. У нас есть структуры, в частности, дто и бизнес-сущности. Сперва мы получаем их из контроллера, вытягиваем их через геттеры и передаем слой бизнес-логики. Там уже, как правило, происходит извлечение соответствующей сущности из базы, над которой впоследствии также выполняются операции с использованием её аксессоров. Потом сущность, возможно, передается в dao-слой, где из неё вытягиваются свойства и куда-то персистятся. Ну и всё тоже обычно справедливо и в обратную сторону - клиенту нужно что-то вернуть.
Только вот инкапсуляции тут ни грамма. IoC вынуждает нас создавать статический граф стейтлесс объектов, которым передаются дата-модели для дальнейшей обработки. Инкапсулировать операции в объектах, создаваемых явно через new, становится намного сложнее из-за того, что им нужно передавать IoC зависимости, которые нужно либо вытягивать из контекста, либо дублировать в классе, порождающем объект, либо выкручиваться как-то иначе.
Инверсия контроля по сути инвертирует ключевую идею ООП, и в таких приложениях класс нельзя назвать сочетанием данных и операций над ними. По сути, приложения ничем не отличаются от классических сишных наборов процедур и структур. А как вы находите компромисс в этой ситуации?

С точки зрения best practices, инверсия контроля очень неплохо обеспечивает соблюдение SRP. Можем создать хоть 10 классов, представляющих операцию над объектом или несколькими, и каждый из них будет заниматься только чем-то конкретным. Только вот это всё - ценой инкапсуляции, применяя которую, в свою очередь, намного сложнее следовать SRP и обеспечивать слабую связанность

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

Каша какая-то

Я правильно понял, ты хочешь понять мысли по поводу богатой и анемичной модели?