Comments on Ewangelizacja IT (Java, Architektura, SOA): Adnotacje kontra XML

Tak jak ktoś wcześniej napisał istotą jest aplikac...

2009-10-17T23:14:42.116+02:00

Tak jak ktoś wcześniej napisał istotą jest aplikacja. Jeśli będą to na przykład serwery giełdowe to bardzo istotne jest że można wymienić ich konfigurację bez restartu. Natomiast jeśli takiej przesłanki nie ma to adnotacje są bliżej kodu z punktu widzenia developera znacznie łatwiej poprawiać błędy czy też panować na kodem po prostu logika i validacja są w jednym miejscu.

"Nic tak naprawdę nas nie ogranicza" no nie do koń...

2008-04-01T09:11:00.000+02:00

"Nic tak naprawdę nas nie ogranicza" no nie do końca, ogranicza nas specyfikacja i trzeba mieć ją na uwadze.
Nieraz już się zdarzało, że proces JSR jest zbyt wolny i powstają własne rozwiązania (Hibernate, Spring), które zawsze są o krok dalej niż specyfikacje ;-)

"... JAXB to jest standard (specyfikacja) ..." i t...

2008-04-01T09:10:00.000+02:00

"... JAXB to jest standard (specyfikacja) ..." i tak i nie ;-)
JAXB to również referencyjna implementacja i stąd moja zagubienie :D

Dodatkowo skoro jest to specyfikacja i korzystamy ...

2008-03-27T18:24:00.000+01:00

Dodatkowo skoro jest to specyfikacja i korzystamy TYLKO z jej interfejsów to sytuacja wygląda tak jakbyśmy korzystali z standardowej paczki javy. Nic tak naprawdę nas nie ogranicza.

Hmmm... "JAXB jest przykładem zależności POJO od k...

2008-03-27T18:12:00.000+01:00

Hmmm... "JAXB jest przykładem zależności POJO od konkretnej implementacji" - JAXB to jest standard (specyfikacja), który może mieć wiele różnych implementacji.

Mój pierwszy wpis był bardzo ogólny, a drugi jest ...

2008-03-27T11:23:00.000+01:00

Mój pierwszy wpis był bardzo ogólny, a drugi jest szczególnym przypadkiem, gdzie nie użyjemy adnotacji. A JAXB jest przykładem zależności POJO od konkretnej implementacji ;-)

Co do "adnotacje powodują, że nasze klasy POJO sta...

2008-03-27T10:51:00.000+01:00

Co do "adnotacje powodują, że nasze klasy POJO stają się zależne od danej implementacji" - hmmm... cała aplikacja jest zależna od technologii których użyliśmy. Jeśli zależy nam na "wolności", to używajmy standardów takich jak JPA. Generalnie, adnotacje nic tu nie zmieniają - jeśli używam np. Hibernate'a a nie JPA to i tak jestem uzależniony. Jeśli go używam, to zakładam że jest mało prawdopodobne bym w przyszłości musiał z niego zrezygnować a więc mało prawdopodobne, że i adnotacje będą mi przeszkadzały.

Co do "model zaszyty w XMLu, a dokładnie w XML Schema, z którego generowane są klasy Java" - tak, jest to typowa sytuacja w rozwiązaniach typu SOA (chyba, że mówisz o jakimś innym przypadku). Model danych zdefiniowany jest w XML Schema a odpowiadające mu klasy są generowane... i jeśli używamy np. JAX-WS to jak najbardziej zawierają adnotacje. Ale tu pełna zgoda, że raczej nie chcemy modyfikować tych klas ręcznie, bo przy następnym generowaniu wszystkie te zmiany zostały by nadpisane. Fakt, w takim przypadku wszelki development chcemy mieć poza tymi klasami, więc adnotacje np. Hibernate czy JPA odpadają, ale adnotacje JAXB jak najbardziej są super (IMHO).

Dlatego też wolę narzędzia. Większość walidacji to...

2008-03-26T19:51:00.000+01:00

Dlatego też wolę narzędzia. Większość walidacji to proste sprawdzanie czy dany ciąg odpowiada wzorcowi, a bardziej skomplikowanych warunków (jeżeli X to Y i user to M to jeżeli a różne od i c nie null to dobrze albo prostszy przykład numer PESEL z datą urodzenia i płcią) i tak nie sprawdzę za pomocą adnotacji. Dla reszty napiszę (napisałem już) narzędzia i tyle...

No nie wiem, czy chciałbyś dla każdego pola swojeg...

2008-03-26T19:46:00.000+01:00

No nie wiem, czy chciałbyś dla każdego pola swojego Entity wpisywać 3-4 różne walidatory, klasa była by kompletnie nieczytelna ;-)
Nie mówiąc o literówkach, których nie jesteś w stanie wyłapać ;-(

tró... zapomniałem, że struktury można generować z...

2008-03-26T19:35:00.000+01:00

tró... zapomniałem, że struktury można generować z xsd. Rzecz oczywista, a uszła mojej uwadze. Walidacja w adnotacjach kontra ta w xmlu... Hm... wolę jednak pisanie w czystej Javie bez xmla i adnotacji. Co za dużo to niezdrowo.

Nie jest to do końca prawda. Klient dla którego pr...

2008-03-26T19:14:00.000+01:00

Nie jest to do końca prawda. Klient dla którego pracuję ma cały model zaszyty w XMLu, a dokładnie w XML Schema, z którego generowane są klasy Java. W takim przypadku nie jesteś w stanie użyć adnotacji.
Druga sprawa to encje to nie jedyny obszar gdzie można używać adnotacji, np. walidacja. Raz, że można ją zmieniać bez rekompilacji i deploymentu aplkacji, co nie zawsze jest proste. Druga spraw, pliki XML można generować, co raczej nie jest możliwe w przypadku adnotacji ;-)
Dlatego twierdzę, że XML i adnotacje będą współistnieć razem, w zależności od potrzeb projektu.

Hm... Zawsze można spróbować używać własnych adnot...

2008-03-26T17:02:00.000+01:00

Hm... Zawsze można spróbować używać własnych adnotacji lub ograniczyć się do adnotacji ze standardu Javy.
Takie przemyślenie, model jest specyficzną częścią każdej aplikacji. Wynika to z faktu, że jest skończony i oddaje określony stan świata w sposób odpowiedni do potrzeb projektu. Przykład to opis samochodu jeżeli prowadzimy salon to uwzględnimy kolor, moc czy też cenę, z drugiej strony jeżeli modelujemy fizykę to ważniejsze będą wymiary czy też moment bezwładności względem jakiejś osi. Powoduje to, że sam model jest ciężki do powtórnego wykorzystania. Idąc dalej tym tokiem możemy założyć, że sposób w jaki skonstruowano model w tym i zależności jest co do zasady niezmienny i nie należy się przejmować tym że tworzone są zależności. Przyjmując dany model stosujemy zasadę wszystko albo nic. Hm... ciekawe czy mnie zrozumieliście.

Wzorzec DTO głównie powstał z myślą o przesyłaniu ...

2008-03-26T16:40:00.000+01:00

Wzorzec DTO głównie powstał z myślą o przesyłaniu obiektów po sieci do zdalnego klienta. I wtedy przesłanie do klienta obiektu encji, mogło powodować problemy z zależnościami po stronie klienta.
Obecnie sam rzadko kiedy stosuje DTO jeśli aplikacja działa w obrębie tej samej maszyny Javy, po prostu to się nie opłaca.
A wracając do tematu, adnotacje powodują, że nasze klasy POJO stają się zależne od danej implementacji. Myślę, że nie da się jednoznacznie odpowiedzieć kiedy używać adnotacji a kiedy xmla.

Co do pierwszego wniosku - zgoda, taki model dział...

2008-03-26T11:01:00.000+01:00

Co do pierwszego wniosku - zgoda, taki model działania - wpierw adnotacje a XML jako patche - jest super dla np. JPA ale niestety Hibernate nie implementuje jeszcze tego w pełni. W Hibernate można nadpisywać w ten sposób tylko adnotacje EJB ale adnotacji specyficznych dla Hibernate już nie - trzeba o tym pamiętać.

Co do drugiego wniosku - zgoda, ale wydaje mi się to być częścią większego problemu. A problem ten to odpowiedź na pytanie - czy powinniśmy używać encji JPA/Hibernate we wszystkich warstwach aplikacji, z widokiem włącznie, czy może warstwa środkowa - tj. serwisy logiki aplikacji - powinny izolować DAO od warstwy widoku? Jeśli powinny izolować, to oznacza to, że encje nie powinny być używane przez warstę widoku i problem wydaje się rozwiązany. Zdaje się, że właśnie po to jest wzorzec DTO.

Cześć,

Poczytałem to co napisałeś i nasunęł...

2008-03-25T21:15:00.000+01:00

Cześć,

Poczytałem to co napisałeś i nasunęły mi się ciekawe wnioski:
- Adnotacje są niezłym rozwiązaniem problemu "konfiguracji domyślnej". To co w XML to nadpisuje to co w adnotacjach. Takie rozwiązanie jest spotykane w np. EJB3. To jest plus.
- Adnotacje nie dają niestety zwykłych POJO. Razem z klasą muszą migrować też odpowiednie zależności dotyczące adnotacji. Może to czasami spowodować nadmierne roztycie aplikacji o w sumie zbędne elementy.