← All posts tagged программирование

IPShuvaev

Верно ли, что любая хорошо спроектированная нетривиальная система превращается в интерпретатор бизнес правил? И возможно ли построить простую в управлении систему без описания ее на предметно-ориентированном языке?

IPShuvaev

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

IPShuvaev

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

IPShuvaev

Допустим, нужно написать типичное веб-приложение, активно работающее с БД, имеющее приличный веб-интерфейс, межмодульное и внешнее rest-api, версию под мобильные устройства, взаимодействющее с внешними сервисами и т.д. Сущностей в приложении — сотни, для каждой по паре view, логика работы с ними зачастую нетривиальна, но в большинстве случаев достаточно однотипна.
Пусть у нас имеется классическая слоеная архитектура: слой контроллеров, слой обработчиков, слой сервисов, слой персистентности. Каждый слой общается с соседним посредством data transfer object, формируемый специальным map-классом. Теперь добавим в систему простейшую сущность:
1. Создаем класс модели.
2. Создаем несколько dto для работы с dao
3. Создаем dao, в нем проксируем вызовы к orm
4. Создаем маппер для отображения dao-dto в модель сущности
5. Создаем сервис, в котором проксируем вызовы к dao и предыдущему мапперу
6. Создаем маппер для отображения модели сущности в client-dto
7. Создаем обработчик, в котором проксируем вызовы к сервису и предыдущему мапперу
8. Создаем контроллер, в котором проксируем вызовы к обработчику
9. Пишем на каждый слой интерфейсы
Бэкенд готов, вроде ничего не забыли. Осталось создать подобные модели, dto, мапперы, контроллеры и проч. на каждом из клиентов и вот, рабочий день подошел к концу.
Вопрос: как сократить весь этот бойлерплейт, не потеряв в гибкости? Есть какая-нибудь альтернативная архитектура/техника и в каких фреймворках она реализована? Причем больше интересуют техники сокращения подобного бойлерплейта в языках со статической типизацией и без всякого рефлекшена.