Dependency injection a tablica obiektów.

Jak w temacie. Jak mam w jakiejś klasie tablice z innymi obiektami, to jak wykorzystując DI Springa, spowodować żeby wszystkie elementy tablicy zostały wypełnione automatycznie?
Drugą sprawą jest, jak mam plik (np) pytania.properties, to jak za pomocą @Values utworzyć kilka obiektów których dane zostałyby odczytane z tego pliku? Tzn do każdego obiektu inna linia. Już nawet wrzuciłem przed każdą linię nr_odpowiedzi_1_a="", nr_odpowiedzi_1_b="", itd itd. I jak zrobić, mając klasę Odpowiedz, zeby przy tworzeniu pierwszej instancji i włożeniu jej do wcześniej wspomnianej tablicy, wartość Stringa była tym co jest w pierwszej linii, drugi obiekt - druga linia itd. Próbowałem wprowadzić zmienne statyczne i to @Values podawać jako nazwę String, który byłby oparty na zmiennych statycznych int i char, ale tak się nie da. Jeszcze co mi do głowy przychodzi z tablicą, to żeby stworzyć ją jako nowego beana, ale to jest bez sensu.
Mniej więcej w takich dwóch klasach chiałbym zrobić przy pomocy DI tablicę obiektów Odpowiedz.

class Pytanie{
String tresc;
Odpowiedz[] odpowiedzi
}

Odpowiedz{
String trescOdpowiedzi;
boolean czyPoprawna;
}

Nie rób tego,kontener IoC nie służy do zarządzania DTO.

Kurde dużo pojęć nie rozumiem, ale staram się na szybko googlować co one znaczą. Dobrze rozumiem, że DTO to są jakieś klasy (czy coś co przechowuje dane) przechowujące jakieś dane tworzone w celu, żeby nie wykonywać kilka razy zapytań w celu uzyskania takich samych danych? Jeśli tak, to czemu nie powinno się używać IoC to tego? I czy nawet w ramach przykładu czy powtórzenia tego nie powinno się używać?

Kontenery IoC służą do zarządzania serwisami, kontrolerami, prezenterami, i innymi obiektami, które mają jakieś zachowanie, a nie pojemnikami na dane jak DTO.

Nie wszystkie obiekty w projekcie powinny być zarządzane przez kontener IoC. Wręcz przeciwnie - obiektów zarządzanych powinno być niewiele i zwykle to będą bezstanowe (!) serwisy. Klasyczny przykład na jeśli masz młotek na nagle wszystko przypomina gwoździe ;]

Bardzo dziękuję za odpowiedzi, jednak mam pytanie. Co znaczy bezstanowe jeśli można wiedzieć?
Ps: czy według Was, spring serio jest tak trudny, że na razie kompletnie nie rozumiem tego, czy wymaga dużo więcej wprawy i abstrakcyjnego myślenia niż w suchej javie?

Bezstanowe - nie posiadające stanu, czyli żadnych wewnętrznych danych, które obiekt zmienia podczas swojego życia.

@Aisekai nie, ale jednocześnie to nie jest coś do pisania hello world i na takich głupich przykładach wydaje sie generalnie bez sensu.
@somekind no aż tak daleko bym nie szedł. Serwis może mieć wewnętrzny stan, czy też swoją konfiguracje. Często ma, np. parametry połączenia z jakimś zewnętrznym serwisem, bazą danych etc. Jednocześnie ta konfiguracja moze też się zmieniać podczas życia sewisu, bo możemy mieć jakieś api do rekonfiguracji.
Cały myk bezstanowości polega na tym że serwis nie przechowuje żadnego pośredniego stanu pomiędzy wywołaniami metod. Bezstanowy obiekt "nie pamięta" wcześniejszych wywołań i generalnie nie ma to dla niego znaczenia. Czyli nie ma tam jakiegoś pojęcia "sesji".

@Shalom, jak się konfiguracja zmienia, to tworzymy nowy serwis. Robienie mutowalnego stanu to proszenie się o problemy.

Nie mylmy teraz bezstanowości z niemutowalnością!

Faktycznie z tą zmienną konfiguracją to moze być problem, bo wymagałoby jakiejś synchronizacji niestety, przynajmniej w ogólnym przypadku ;)
Niemniej taki serwis nadal moze mieć coś w stylu mutowalnego wewnętrznego cache -> jest tam wtedy pewien stan i jest on zmienny, bo cache może działać na zasadzie kolejki LRU, ale mimo wszystko generalnie nadal mamy coś co jest stateless. Jest tu pewien niewielki spadek wydajności przy operacjach na kolejce, ale załóżmy że zysk z cache jest dużo większy.

Faktycznie często statelss idzie w parze z immutable, ale nie musi tak zawsze być. Z jednej strony mamy thread safety z definicji, ale z drugiej strony możemy mieć właśnie jakieś cuda w stylu cache.

Obiekt który nie jest immutable musi zadbać o to, żeby bezpiecznie (z punktu widzenia dostarczanych funkcji) i atomowo zmienić stan.
Obiekt który jest stateful to jest zupełnie inny poziom skomplikowania, bo nagle musimy pamiętać kto, kiedy i jak uzywał tego obiektu, bo każde kolejne wywołanie zależy od poprzenich i ma wpływ na kolejne.