Bean a właściwości

Cześć.
Czy dobrą praktyką jest dodawanie do beanów jakiś właściwości (private) i wykonywać settery i gettery ?
Serwisy muszą być bezstanowe, ale jak to jest z beanami?
Moim zdaniem to zła praktyka ponieważ całość może się "pomieszać" na operacjach wielowątkowych - poza tym, po co w beanach, które wstrzykujemy za pomocą DI mieć jakieś właściwości / gettery i settery (tutaj nie potrafię sobie wyobraźić sytuacji) jeśli chcemy mieć jakiś stan to warto chyba utworzyć zwykłą klasę (nie bean) i przekazywać ją do odpowiednich odpowiednio manipulując właściwościami.

Masz na myśli Springa czy JavaEE? Beany to klasy zarządzane przez kontener IoC i za bardzo nie rozumiem twojego rozróżnienia serwisy a beany, przecież serwis może być beanem.
A do czego te beany mają służyć? W serwisach faktycznie nie ma sensu moim zdaniem umieszczać getterów i setterów. Co do tej klasy (nie bean) to chyba masz na myśli dedykowane DTO do metody serwisowej.

Kluczowe pytanie, jakie konkretnie beany rozważasz/rozkminiasz?

Edit:
Nie wiem, może za cienki w uszach jestem ale jak masz wielowątkowość w aplikacji używającej Springa to chyba something is f*cking wrong.

Chodzi stricte o Springa.

Ogólnie rozkminiam przypadek w którym gettery i settery w beanie będą uzasadnione, beany najczęściej wstrzykujemy przez konstruktor bez inicjalizacji obiektu, więc po co tutaj jakieś właściwości i przeze wszystkim settery.

Moim zdaniem na drugim wątku (nawet w springu) można odpalić jakiś inny proces, który trochę trwa aby klient mógł sobie na innym wątku działać a na drugim leci jakiś proces który odpalił wcześniej.

Sumekprog napisał(a):

Chodzi stricte o Springa.

Ogólnie rozkminiam przypadek w którym gettery i settery w beanie będą uzasadnione, beany najczęściej wstrzykujemy przez konstruktor bez inicjalizacji obiektu, więc po co tutaj jakieś właściwości i przeze wszystkim settery.

Moim zdaniem na drugim wątku (nawet w springu) można odpalić jakiś inny proces, który trochę trwa aby klient mógł sobie na innym wątku działać a na drugim leci jakiś proces który odpalił wcześniej.

No teraz rozumiem Cię lepiej, nie wiem jak inni na forum ale ja generalnie w pracy nie spotykam się z czymś takim aby serwisy miały settery i gettery. Jak masz bezstanowy serwis i dwa asynchroniczne taski korzystające z tego serwisu to problemu nie ma - ale o tym napisałeś. Pytanie po co właściwości i settery: odpowiedź brzmi zapewne, "bo można". Bo architektura Springa na to pozwala to dali taką możliwość. Widziałem w projekcie zależności ustawiane przez setter z @Requied ale przeważnie wynikało to zapewne "z braku doświadczenia piszącego". Tzn. może ktoś inny się wypowie ale ja bym sobie głowy tym nie zawracał i nie używał / niech ktoś mnie poprawi i uświadomi o czymś o czym nie wiem.

Edit:
Widziałem chyba w projekcie z JBossem 4 w JavaEE ustawianie zależności przez settery ale to dlatego że JavaEE była za głupia aby ogarnąć to konstruktorem / bean musiał mieć bez argumentowy konstruktor z czego wynika że właściwości to jakaś zaszłość z przeszłości.

Nie bardzo rozumiem pytanie. Bean/serwis mogą mieć jakiś wewnętrzny stan i zwykle mają. Ot np. jakis cache chociażby, żeby nie wykonywać niepotrzebnie tych samych ciężkich operacji, albo trzymasz jakieś informacje o sesji użytkowników w pamięci itd.
Bezstanowość oznacza tyle, że nie zakładasz nic na temat działania pomiędzy wywołaniami operacji na serwisie, bo takie coś przy wielu dostępach się pomiesza. W takiej sytuacji używa się takich rzeczy jak ConcurrentHashMap, AtomicReference i innych cudów z serii concurrent.

Więc np. nie możesz zakładać ze robisz jakieś store a potem execute i że nikt w międzyczasie ci tego nie nadpisze (albo ze w ogóle uderzysz 2 razy w ten sam node z aplikacją!). Ale nic nie stoi na przeszkodzie zrobić store które zwraca unikalne UUID, które możesz potem wykorzystać wywołując execute, a wewnętrznie masz tam jakieś ConcurrentHashMap<UUID, Cośtam>.
Oczywiście coś takiego się psuje jak masz wiele nodów aplikacji i problem się komplikuje, bo trzeba dołożyc tam jakiegoś Hazelcasta albo Redisa, albo coś podobnego, żeby współdzielić stan pomiędzy nodami...

Sumekprog napisał(a):

Cześć.
Czy dobrą praktyką jest dodawanie do beanów jakiś właściwości (private) i wykonywać settery i gettery ?
Serwisy muszą być bezstanowe, ale jak to jest z beanami?
Moim zdaniem to zła praktyka ponieważ całość może się "pomieszać" na operacjach wielowątkowych - poza tym, po co w beanach, które wstrzykujemy za pomocą DI mieć jakieś właściwości / gettery i settery (tutaj nie potrafię sobie wyobraźić sytuacji) jeśli chcemy mieć jakiś stan to warto chyba utworzyć zwykłą klasę (nie bean) i przekazywać ją do odpowiednich odpowiednio manipulując właściwościami.

Z definicji bean powinien posiadać pola prywatne, bezargumentowy konstruktor, gettery/settery i być serializowany, więc to raczej nie jest kwestia dobrej praktyki, a raczej samego standardu. https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/

Z tymi operacjami wielowątkowymi to trochę przesada, jak się to przyzwoicie ogarnie, to nie ma z tym żadnych problemów, tylko trzeba w to zainwestować.
Obecnie pracuję w projekcie w banku i ktoś kto zrobił managera do wątków serio powinien dostać jakąś nagrodę z dziedziny inżynierii. Nie wiem, złotą śrubkę i list dziękczynny od rodzin prezesów banku, bo zrobił kawał dobrej roboty.

@trojanus absolutnie nie :) JavaBeans to prehistoria i coś zupełnie innego niż bean Springowy, który jest definiowany w dokumentacji Springa jako: A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Nie musi być ani serializowalny, ani nie musi posiadać bezargumentowego konstruktora. To bardziej nawiązanie do EJB.

W 99% przypadków nie ma potrzeby dodawać do beanów getterów/setterów - jeśli uważasz, że potrzebujesz, to najpewniej robisz coś źle.

@Charles_Ray: cóż, jak widzę bean to mam na myśli JavaBean i EJB, bo w takim projekcie robię. 3/4 klas mamy oblepione lombokiem, a DI przez konstruktor to nie widziałem od lutego, bo wtedy zmieniałem pracę i trafiłem na dość zabetonowany projekt. Ale jest nadzieja, że może w przyszłym roku przejdziemy na springa i jave 8, bo coś przebąkiwali, żeby im wyceny zrobić. xD