Каков правильный способ моделирования совокупных объектов?

Question

У меня есть два объекта домена: Employee и Team. Как вы можете догадаться, у команды 0 ... * Employee s. что правильно их моделировать?

вариант 1:

class Team{ 
    List<Employee> members; 
} 

это может быть, самый интуитивный способ, но это означает, что, когда мне нужно только для отображения Team Infos, я должен загрузить много Employee с, что является полностью отходы. может быть, я могу добавить немного ленивые нагрузки (может бросить прокси) механизм, но это принесет нам много сложностей

варианта 2:

class Team{ 
    List<Long> memberIds; 
} 

эта опция не будет загружать слишком много ненужных Employee сек, но может быть (Я не уверен) не хороший дизайн с точки зрения моделирования

вариант 3:

class Team{} 
class Employee{ 
    Team team; 
} 

в этой опции я могу запросить Team ' s Employee s пользователем Employee Недвижимость. Но я думаю, может быть (я не уверен), с точки зрения моделирования, Employee не должен иметь знания о том, как она организована, а также Employee является юридическим лицом, которое может жить без Team

Что вы думаете ребята?

Answer 1

Первый вариант простой & лучший.

class Team{ 
    List<Employee> members; 
} 

Вы можете установить пакетный размер в Hibernate, или многие другие реализации JPA, так что, когда сотрудники действительно должны быть выбраны, они выбираются 10 в то время, или сконвертировано. Это займет мало времени, и Hibernate не будет получать коллекцию, пока вы ее не потребуете.

«Набор идентификаторов» не помогает - он не содержит имен членов команды, и он не ускоряет загрузку, когда они вам понадобятся.

Общее правило: не оптимизируйте, пока вам не понадобится.

Но есть две альтернативы, вы можете рассмотреть, если вам нужно:

1. Включите EH-Cache или аналогичный кэш второго уровня для Team.members и сотрудников;
2. Храните объединенные имена членов команды в команде. Примечания: Это будет иметь ограниченные гарантии актуальности и должно быть усечено, чтобы избежать переполнения максимального размера столбца.

Но как «ориентировочный отображаемый текст», а не авторитетное значение, второй вариант будет в порядке.

Answer 2

Вы должны учитывать тот факт, что у вас не должно быть членов вашей команды, логически равных друг другу (или, может быть, вам нужно 1000 клонов «Агент Смит», сражающихся за вашу команду :-)). Лучше моделировать отношения, как это:

Set<Employee> members;