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

Скорее наоборот. Пока что в этом сервисе представлена только незначительная часть залов (если смотреть Rijksmuseum, к примеру). Больше похоже на рекламу: хотите увидеть больше — приходите.

Ох, кода много вставлять придется. Не кошерно получится. Из базы вытаскивается только то, что нужно.

У прокси внутри лежит Map [имя поля -> значение]. Значения в нем — это или примитивные типы или другие прокси. Прокси, при обращении к полям возвращает или записывает значение из мэпа.

Хибернейтовские сущности в прокси не попадают. Entity-поля заменяются прокси.

Мне кажется, в построении команды применим подход «Добавляй людей в команду, только если не можешь не добавить». Иначе в итоге получается, что тратишь время:

1. на то, чтобы придумать, какое задание дать человеку
2. на формальное описание, того что нужно сделать
3. на проверку сделанного

Т.е. больше времени уходит на разъяснения.

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

Не знал про Spring Roo. Похоже, очень полезный интсрумент. Почитаю про него и напишу.

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

«И ещё — почему вы всёже не остановились на DTO?» — А это и есть DTO :)

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

Насчет глубоких уровней вложенности — так данный подход как раз позволяет регулировать с точностью до поля уровень вложенности:

Допустим, есть интерфейсы IItem и IStrippedItem:

public interface IItem {
    int getId();
    void setId(int);

    List<IStrippedItem> getChildren();
    void setChildren(List<IStrippedItem> items);
}

public interface IStrippedItem {
    int getId();
    void setId(int);
}

Если запроксировать сущность к IItem, то дети детей проксироваться не будут.

Согласен, есть такой момент. Приходится прокси интерфейсами отражать сущности. Немножко запаривает. Но запаривает недостаточно, чтобы взяться и переписать всё это используя CGLIB и, соответственно «гибридизировать» прокси систему так, чтобы простые сущности она отдавала «как есть».

Для использования это совершенно не громоздко. Просто нужно написать интерфейс и все. Буквально.

Имплементация тоже достаточно простая. Насчет средств Hibernate — не скажу, что считаю себя большим специалистом в этой технологии. В основном я работал на уровне JPA. Но по-моему там нет ничего, что позволяло бы делать прокси методом «написал интерфейс и готово».

А что за проекции?

В данном конкретном случае была использована парадигма «Преждевременная оптимизация — корень всех зол» :)

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

Написал на эту тему пост: habrahabr.ru/blogs/java/112621/

Михаил, спасибо за инвайт :)