17 maja 2009
Jadę na Democamp
Właśnie zrobiłem rezerwacje na sobotnio-niedzielny Democamp odbywający się w Poznaniu. Tematyka startupów stała mi się ostatnio dość bliska, gdyż sam aktualnie pracuję nad jednym autorskim projektem. Kto wie, może któregoś dnia sam znajdę się po stronie prezentujących swój pomysł, więc póki co warto zobaczyć jak to robią inni zanim samemu przyjdzie stanąć przed publicznością. Jeśli kogoś ten temat zainteresował to polecam blog Antyweba oraz serwis Techcrunch. W przypadku, gdy samemu chce się śledzić pojawiające się polskie startupy to zapraszam na Startups.pl Informacje na temat prezentowanych witryn biorących udział w Democampie można znaleźć tutaj.
16 maja 2009
Spring Framework 3.0.0.M3 i Maven
Ostatnio zdarza mi się częściej używać Mavena, co jest generalnie ciekawym doświadczeniem, aczkolwiek czasami frustrującym. To ostatnie dopadło mnie przy próbie integracji ze Spring Framework. Na stronie projektu pokazany jest przykład integracji Springa z Mavenem. Repozytoria, z których można pobrać Springa są następujące:
Przeglądać repozytoria można pod tym adresem. Teraz przyszedł czas, żeby zdefiniować zależności wskazujące na biblioteki jakich chcemy użyć w naszym projekcie. Tutaj mała wzmianka. Nazewnictwo artefaktów uległo zmianie w stosunku do poprzednich wydań Springa, więc migracja ze starszych wersji dla projektów używających Mavena może okazać się kłopotliwa.
Wydawać by się mogło, iż to już wystarczy. Niestety nie. Przy próbie ściągnięcia bibliotek okazuje się, że w repozytorium Springa nie ma wszystkich bibliotek, z których korzysta Spring. Prawdę mówiąc na tym etapie utknąłem. Na szczęście, ktoś wcześniej miał podobny problem i zasugerował dodanie repozytorium Atlassiana.
Powyższe przygody sprawiają, że ciśnienie Ci wzrasta. Problem z zależnościami jest częstym przeżyciem dla użytkowników Mavena. Nie wiem do końca z czego to wynika? Czy problem leży po stronie twórców Mavena? Czy może ludzie, którzy umieszczają swoje biblioteki w publicznych repozytoriach nie zawsze dbają w należyty sposób o to, aby pobranie bibliotek odbywało się bezproblemowo?
springsource-milestone
http://repository.springsource.com/maven/bundles/milestone
springsource-release
http://repository.springsource.com/maven/bundles/release
springsource-external
http://repository.springsource.com/maven/bundles/snapshot
Przeglądać repozytoria można pod tym adresem. Teraz przyszedł czas, żeby zdefiniować zależności wskazujące na biblioteki jakich chcemy użyć w naszym projekcie. Tutaj mała wzmianka. Nazewnictwo artefaktów uległo zmianie w stosunku do poprzednich wydań Springa, więc migracja ze starszych wersji dla projektów używających Mavena może okazać się kłopotliwa.
org.springframework
org.springframework.core
3.0.0.M3
Wydawać by się mogło, iż to już wystarczy. Niestety nie. Przy próbie ściągnięcia bibliotek okazuje się, że w repozytorium Springa nie ma wszystkich bibliotek, z których korzysta Spring. Prawdę mówiąc na tym etapie utknąłem. Na szczęście, ktoś wcześniej miał podobny problem i zasugerował dodanie repozytorium Atlassiana.
atlassian-m2-repository
https://m2proxy.atlassian.com/repository/public
Powyższe przygody sprawiają, że ciśnienie Ci wzrasta. Problem z zależnościami jest częstym przeżyciem dla użytkowników Mavena. Nie wiem do końca z czego to wynika? Czy problem leży po stronie twórców Mavena? Czy może ludzie, którzy umieszczają swoje biblioteki w publicznych repozytoriach nie zawsze dbają w należyty sposób o to, aby pobranie bibliotek odbywało się bezproblemowo?
14 maja 2009
Dołączenie źródeł do Eclipse'a za pomocą Mavena
Ciekawą cechą mavenowego pluginu dla eclipse'a jest możliwość dołączenia dokumentacji do używanych bibliotek. Odbywa się to w bardzo prosty sposób. Mając stworzony projekt przy użyciu Mavena w linii poleceń wpisujemy standardowe polecenie generujące niezbędne pliki potrzebne do rozpoznania naszego projektu przez Eclipse'a, ALE czynność tą popełniamy z dodatkowym parametrem:
mvn eclipse:eclipse -DdownloadSources=true
Prawie gotowe! Jeśli wcześniej mieliśmy otwarty owy projekt w Eclipsie, to wystarczy w Package Explorerze (czy też w Navigatorze) kliknąć na katalog z nazwą projektu i wcisnąć F5 w celu odświeżenia konfiguracji projektu. Od tego momentu cieszymy się możliwością przeglądania dokumentacji używanych bibliotek. Dzieje się tak po najechaniu myszką na nazwę klasy albo metody.
mvn eclipse:eclipse -DdownloadSources=true
Prawie gotowe! Jeśli wcześniej mieliśmy otwarty owy projekt w Eclipsie, to wystarczy w Package Explorerze (czy też w Navigatorze) kliknąć na katalog z nazwą projektu i wcisnąć F5 w celu odświeżenia konfiguracji projektu. Od tego momentu cieszymy się możliwością przeglądania dokumentacji używanych bibliotek. Dzieje się tak po najechaniu myszką na nazwę klasy albo metody.
24 kwietnia 2009
Załapałem się
Uff zdążyłem... Na blogu Grzegorza Dudy dowiedziałem się, że Atlassian zrobił promocję i umożliwił zakup rocznej licencji na JIRA i Confluence (po $5.00 za każdy produkt, co przy ASTRONOMICZNYCH cenach tych produktów wydaje się być okazją). Zakup licencji zawiera roczny maintence. Należy również wspomnieć, iż owa licencja obejmuje możliwość użytkowanie oprogramowania przez pięciu użytkowników, co w moim wypadku w zupełności wystarcza. Przy zakupie była opcja przedłużenia licencji na kolejne dwa lata co również uczyniłem. Szczerze mówiąc, jak zobaczyłem, że termin promocji upływa 24 kwietnia nie wgłębiałem się w warunki licencji tylko szybko zabierałem się za rejestrację, gdyż nie byłem pewien w obrębie jakiej strefy czasowej odbywa się owa promocja, a tu należy wspomnieć, że siedzibą Atlassiana jest Australia. W każdym razie udało się. :)
Pozdrawia szczęśliwy posiadacz JIRA i Confluence
Pozdrawia szczęśliwy posiadacz JIRA i Confluence
9 kwietnia 2009
Wielożeństwo czyli integracja Mavena z ICEfaces 1.8.0 i Tomahawk 1.1.8
Niedawno znalazłem się na zielonej trawce, więc jest trochę więcej czasu na rzeczy na które wcześniej go brakowało. Przy okazji pracy przy swoim prywatnym projekcie chciałbym zaprezentować integrację ICEfaces 1.8.0 z Tomahawk 1.1.8 przy użyciu Mavena. Jako kontenera serwletów użyę Tomcata 6.
Tak sie składa, że na dniach wyszła stabilna wersja ICEfaces w wersji 1.8.0. Jednakże o ile się nie mylę, to wciąż brakuje w niej gotowych walidatorów (np. e-maila, czy też porównania dwóch haseł przy ekranie z rejestracją). Te dobrodziejstwa są natomiast dostępne w Tomahawk. Niby są to małe rzeczy, ale po co się nadmiernie meczyć? Więc do roboty...
Ze strony ICEfaces pobieramy specjalną paczkę przeznaczoną dla Mavena i po rozpakowaniu kopiujemy ją do katalogu naszego lokalnego repozytorium. W moim Ubuntu jest to katalog .m2, który znajduje się w moim katalogu domowym natomiast dla systemu Windows będzie to C:\Documents and Settings\twójlogin\.m2\repository
Teraz esencja czyli pom.xml. Plik ten został stworzony na podstawie jednego z tutorialowych przykładów ICEfaces. Niestety nie może być zbyt pieknie. Owy pom trzeba w niektórych miejscach przeedytować, aby wszystko razem zgodnie współpracowało. Odpuszczę sobie zbędne gadulstwo, tylko zamieszczę poniżej końcową jego wersję:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>pl.syllepsa</groupId>
<artifactId>myapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>myapp Maven Webapp</name>
<url>http://maven.apache.org</url>
<build>
<finalName>myapp</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>tomcat6</server>
</configuration>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>jboss-maven-repository</id>
<url>http://repository.jboss.com/maven2</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.apache.myfaces.tomahawk</groupId>
<artifactId>tomahawk</artifactId>
<version>1.1.8</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-comps</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-facelets</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
<exclusion>
<artifactId>commons-logging-api</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<profiles>
<profile>
<id>tomcat6</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf-version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-el</groupId>
<artifactId>commons-el</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>commons-discovery</groupId>
<artifactId>commons-discovery</artifactId>
<version>0.4</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<properties>
<!--
since no more versions of jsf1.1 are being developed, just
jsf-version property for jsf1.2
-->
<!-- <jsf-version>1.2-b19</jsf-version>-->
<jsf-version>1.2_12</jsf-version>
</properties>
</project>
W przykładzie Timezone7 z tutoriala ICEfaces prezentujacego integrację z Mavenem (przykład jest na miejscowym forum) wszystko wygląda pięknie, ale nie działa. Należy jeszcze poddać edycji plik web.xml i ustawić na wartość false parametry:
1. com.sun.faces.validateXml
2. com.sun.faces.verifyObjects
Na koniec w konsoli wpisujemy: mvn tomcat:deploy Przy założeniu, że macie stworzony jakiś przykładowy widok. Zakładam również, że skonfigurowany jest dostę do tomcata z poziomu mavena. Niejaki Pan Koziołek opisał to kiedyś dokładnie.
To chyba tyle. Powinno śmigać.
Korzystając z okazji życzę Wam owocnego przeżywania Świąt Wielkiej Nocy, a po Świętach uczestnictwa w wielu ciekawych projektach.
Mariusz
Tak sie składa, że na dniach wyszła stabilna wersja ICEfaces w wersji 1.8.0. Jednakże o ile się nie mylę, to wciąż brakuje w niej gotowych walidatorów (np. e-maila, czy też porównania dwóch haseł przy ekranie z rejestracją). Te dobrodziejstwa są natomiast dostępne w Tomahawk. Niby są to małe rzeczy, ale po co się nadmiernie meczyć? Więc do roboty...
Ze strony ICEfaces pobieramy specjalną paczkę przeznaczoną dla Mavena i po rozpakowaniu kopiujemy ją do katalogu naszego lokalnego repozytorium. W moim Ubuntu jest to katalog .m2, który znajduje się w moim katalogu domowym natomiast dla systemu Windows będzie to C:\Documents and Settings\twójlogin\.m2\repository
Teraz esencja czyli pom.xml. Plik ten został stworzony na podstawie jednego z tutorialowych przykładów ICEfaces. Niestety nie może być zbyt pieknie. Owy pom trzeba w niektórych miejscach przeedytować, aby wszystko razem zgodnie współpracowało. Odpuszczę sobie zbędne gadulstwo, tylko zamieszczę poniżej końcową jego wersję:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>pl.syllepsa</groupId>
<artifactId>myapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>myapp Maven Webapp</name>
<url>http://maven.apache.org</url>
<build>
<finalName>myapp</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>tomcat6</server>
</configuration>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>jboss-maven-repository</id>
<url>http://repository.jboss.com/maven2</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.apache.myfaces.tomahawk</groupId>
<artifactId>tomahawk</artifactId>
<version>1.1.8</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-comps</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-facelets</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
<exclusion>
<artifactId>commons-logging-api</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<profiles>
<profile>
<id>tomcat6</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf-version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-el</groupId>
<artifactId>commons-el</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>commons-discovery</groupId>
<artifactId>commons-discovery</artifactId>
<version>0.4</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<properties>
<!--
since no more versions of jsf1.1 are being developed, just
jsf-version property for jsf1.2
-->
<!-- <jsf-version>1.2-b19</jsf-version>-->
<jsf-version>1.2_12</jsf-version>
</properties>
</project>
W przykładzie Timezone7 z tutoriala ICEfaces prezentujacego integrację z Mavenem (przykład jest na miejscowym forum) wszystko wygląda pięknie, ale nie działa. Należy jeszcze poddać edycji plik web.xml i ustawić na wartość false parametry:
1. com.sun.faces.validateXml
2. com.sun.faces.verifyObjects
Na koniec w konsoli wpisujemy: mvn tomcat:deploy Przy założeniu, że macie stworzony jakiś przykładowy widok. Zakładam również, że skonfigurowany jest dostę do tomcata z poziomu mavena. Niejaki Pan Koziołek opisał to kiedyś dokładnie.
To chyba tyle. Powinno śmigać.
Korzystając z okazji życzę Wam owocnego przeżywania Świąt Wielkiej Nocy, a po Świętach uczestnictwa w wielu ciekawych projektach.
Mariusz
29 stycznia 2009
Spring BlazeDS
Wczoraj niezmiernie ucieszyła mnie informacja na InfoQ o tym, że SpringSource połaczył swe siły z Adobe w projekcie Spring BlazeDS. Na początku powinienem wspomnieć coś na temat samego projektu BlazeDS.
Otóż BlazeDS jest technologią uruchamianą po stronie serwera umożliwiającą komunikację pomiędzy Javą a technologią Adobe Flex i Adobe AIR, które pełnią funkcję widoku. Komunikacja odbywa się za pomocą protokołu AMF lub SOAP. Jakiś rok temu testowałem przykładowy kod korzystając zarówno z AMF jak i SOAP i pewnie nikogo to nie zdziwi, ale komunikacja przez AMF postępowała bardziej chyżo.
Co natomiast daje nam Spring BlazeDS ? Ano to, że mamy teraz dostęp do BlazeDS MessageBrokera jako do beana Springa. Dokładniej mówiąc oddzielnie trzymana jest (raczej niezmienna) konfiguracja BlazeDS, która zawiera definicję właściwości kanału AMF i oddzielnie konfigurowane jest źródło danych znane powszechnie z aplikacji Springowych.
Wydaje mi się, że wciąż konieczne jest używanie skrypletów w Action Scripcie dla akcji wysyłających dane do serwera. Może kiedyś będzie to rozwiązane przez projekt opakowujący komponenty Flexa w JSF. Wiem, że takowy już istnieje, ale go już dawno nie śledziłem.
Odnośniki:
http://www.infoq.com/news/2009/01/spring-adobe-blazeds
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://blog.springsource.com/2008/12/17/using-spring-blazeds-integration-m1/
Otóż BlazeDS jest technologią uruchamianą po stronie serwera umożliwiającą komunikację pomiędzy Javą a technologią Adobe Flex i Adobe AIR, które pełnią funkcję widoku. Komunikacja odbywa się za pomocą protokołu AMF lub SOAP. Jakiś rok temu testowałem przykładowy kod korzystając zarówno z AMF jak i SOAP i pewnie nikogo to nie zdziwi, ale komunikacja przez AMF postępowała bardziej chyżo.
Co natomiast daje nam Spring BlazeDS ? Ano to, że mamy teraz dostęp do BlazeDS MessageBrokera jako do beana Springa. Dokładniej mówiąc oddzielnie trzymana jest (raczej niezmienna) konfiguracja BlazeDS, która zawiera definicję właściwości kanału AMF i oddzielnie konfigurowane jest źródło danych znane powszechnie z aplikacji Springowych.
Wydaje mi się, że wciąż konieczne jest używanie skrypletów w Action Scripcie dla akcji wysyłających dane do serwera. Może kiedyś będzie to rozwiązane przez projekt opakowujący komponenty Flexa w JSF. Wiem, że takowy już istnieje, ale go już dawno nie śledziłem.
Odnośniki:
http://www.infoq.com/news/2009/01/spring-adobe-blazeds
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://blog.springsource.com/2008/12/17/using-spring-blazeds-integration-m1/
26 stycznia 2009
Dlaczego nie warto trzymać transakcji w metodach klasy DAO
Wzorzec Data Access Object zwany w skrócie DAO jest wzorcem projektowym związanym z warstwą integracji. Klasa DAO zawiera metody odwołujące się do tzw. data storage, którym jest zazwyczaj baza danych. Wyobraźmy sobie sytuację, że musimy dokonać podmiany danych użytkownika, gdyż zmienił się jego adres zamieszkania. Procedura działania jest następująca:
1. Odszukanie użytkownika na podstawie jakiegoś identyfikatora
2. Pobranie adresu użytkownika
3. Ustawienie nowego adresu i zapisanie zmian do bazy danych
Każdy z tych punktów możemy traktować jako wywołanie pojedynczej metody obiektu (lub tez obiektów DAO). W standardowych przypadkach byłoby nierozsądnym otwieranie i zamykanie transakcji dla każdej z tych metod z osobna, gdyż niepotrzebnie zwiększałoby to wykorzystanie zasobów. Dodatkowo niepowodzenie jednego z trzech punktów powinno spowodować powrót bazy do stanu przed rozpoczęciem procesu uaktualniania adresu użytkownika. Rozwiązaniem nowej klasy zawierającej metodę w ramach, której wywoływane są poszczególne metody obiektu DAO. Dopiero tutaj, na początku tejże nowej metody otwieramy transakcję, która zamykana jest po wywołaniu ostatniej metody obiektu DAO. Czyli metody zapisującej nowy adres do bazy danych. W ten oto sposób popełniliśmy niechcąco wzorzec Application Service.
1. Odszukanie użytkownika na podstawie jakiegoś identyfikatora
2. Pobranie adresu użytkownika
3. Ustawienie nowego adresu i zapisanie zmian do bazy danych
Każdy z tych punktów możemy traktować jako wywołanie pojedynczej metody obiektu (lub tez obiektów DAO). W standardowych przypadkach byłoby nierozsądnym otwieranie i zamykanie transakcji dla każdej z tych metod z osobna, gdyż niepotrzebnie zwiększałoby to wykorzystanie zasobów. Dodatkowo niepowodzenie jednego z trzech punktów powinno spowodować powrót bazy do stanu przed rozpoczęciem procesu uaktualniania adresu użytkownika. Rozwiązaniem nowej klasy zawierającej metodę w ramach, której wywoływane są poszczególne metody obiektu DAO. Dopiero tutaj, na początku tejże nowej metody otwieramy transakcję, która zamykana jest po wywołaniu ostatniej metody obiektu DAO. Czyli metody zapisującej nowy adres do bazy danych. W ten oto sposób popełniliśmy niechcąco wzorzec Application Service.
Subskrybuj:
Posty (Atom)
