Witam. To mój pierwszy post na tym forum. Jeśli w złej kategorii umieściłem ten post to przepraszam.
Mam do napisania projekt w MVC. Mam do tego celu zastosować technologię ORM (Propel) i z tym nie mam problemów.
Użycie tej technologii wymusza zastosowanie Transfer Object.
Mam także zastosować pakiet XML-RPC http://phpxmlrpc.sourceforge.net
Wykorzystując te 3 technologie mam zrobić projekt w 3-warstwowej architekturze MVC.
Nie wiem jak ma wyglądać ten pakiet Transfer Object bo rozumiem, że muszę go sam napisać. Z tego co czytałem i już wiem to chodzi w tym o to żeby tzw. komponenty encyjne z Propela były przenoszone do wyższych warstw jako kopie np. warstwa logiki używając ORM do zrobienia select'a tworzy komponent encyjny, zamienia go na TO i zwraca do wyższych warstw.

Komunikacja między view a logiką powinna odbywać się za pomocą XML-RPC. O tym też nie mam pojęcia. Ściągnąłem skrypt ale nie wiem jak i po co go stosować 8-(

W związku z tym mam pytanie. Może ktoś już coś podobnego tworzył? Może ktoś mógłby mi to jakoś wyjaśnić.

Jeśli niejasno napisałem to proszę pytać a ja będe próbował jaśniej to napisać.

Pozdrawiam

Jeżeli dobrze zrozumiałem chcesz przesyłać obiekty XML-RPCem? Tak?
Takie obiekty musisz sobie sam napisać, Propel ładuje zbyt dużo logiki w swoje, która po zdeserializowaniu nie będzie potrzebna.
O tyle dobrze, że jeżeli będziesz się kierował ku prawdziwemu MVC, gdzie autentycznie opakujesz Propela modelem, to nie powinieneś mieć problemów. Takie podejście wymusza na tobie jakiś rodzaj interfejsu pomiędzy modelem, a widokiem (w sensie, że nie będziesz do widoku przekazywał obiektów Propela, bo mijało by się to z celem). Stawiałbym na zwykłe tablice: Są nośnikiem tylko danych i łatwo się serializują.

Tego nie rozumiem za bardzo. Czy to znaczy, że będziesz miał 2-ie aplikacje? Jedna do pobierania danych z bazy i wysyłania Ich XMLem do drugiej aplikacji, która to dopiero pokaże jakieś rezultaty?

Pozdrawiam, Alan

edit:

W grę wchodzi jeszcze JSON, jako że jest obsługiwany przez znakomitą większość platform (nie musiałbyś wciskać własnego serializatora i deserializatora)

Chcesz używać XMLRPC wewnętrznie? Przesyłając DTO pomiędzy składowymi MVC?



I to rozumiem, bo model ukrywa implementacje - mógłbyś tam użyć czegokolwiek: Propela, Doctrine czy natywnych tj. PDO.
I nie widzę sensu, żeby model zwracał obiekty Propela, skoro ma je ukrywać.



Jestem zdezorientowany. Jakiego frameworka używasz?

ten projekt mam zrobic na prace.

Takie technologie zaproponowal mi opiekun pracy. Projekt mam wykonac w UML nastepnie zaimplementowac wykorzystujac te technologie. Sam nie wiem po co mi do tego ten caly xml-rpc. O RPC uczylem sie na jezyku C o zdalnym wywolywaniu procedur i nie wiem czy tutaj tez bede zdalnie cos wywolywal czy jak. 

Moim zdaniem to wygląda inaczej - znacznie inaczej.
MVC to sposób tworzenia aplikacji:
1. W modelu masz Propela, która zwraca dane do...
2. ...Kontrolera, a ten sprawdza, czy wszystko okay i przekazuje te dane do...
3. Widoku, który może wypluć HTMLa, JSONa, czy XML w formacie XML-RPC

Z tym, że aplikacja musi potrafić też przyjąć żądanie XML-RPC i je odpowiednio zmapować na kontroler/akcje.

Ja nie rozumiem po co mi w tym moim projekcie tego xml-rpc? Przecież bez tego też będzie można przekazywać obiekty transferowe pomiędzy warstwami?
A jak ma wyglądać przykladowa klasa DTO? Mam np. klasę ksiazka ktora jest komponentem encyjnym z Propela. Tworze sobie obiekt np ksiazka1 wypełniam go danymi i na końcu daje ksiazka1->save();
A jak to będzie wyglądać z zastosowaniem klasy ksiazkaDTO?

Ale kto robi aplikację MVC w której komponenty przesyłają sobie dane przez sieć?
To twoja aplikacja powinna oferować wysyłanie danych przez ten format. Ja i przez SOAP, JSON, czy HTML.

A tak, to jej wewnętrzna sprawa jak sobie będzie przesyłać dane między modelem a kontrolerem a widokiem - może to być tablica, jakiś obiekt w granicach języka implementacji.

Ale napiszcie mi co robi konkretnie xml-rpc? Wywołuje zdalnie metody? tak jak RPC  w jezyku C. Po co ono w ogole jest?
Jeśli chodzi o transfer object to te klasy maja jedynie przenosic kopie obiektów pomiędzy warstwami.

Może ja to w ogole zle rozumuje? Czy DTO będzie działać bez xml-rpc?

edit:
Napiszę o co mi chodzi odpowiadając bezpośrednio na twoje pytania. Tak będzie łatwiej.


Jak wyżej.



Bo to jest klasa implementująca ORM. posiada metody do zapisu, czy update'u.



Żadna. Model po prostu wypluwa dane. I ważne, żeby to był uniwersalny nośnik (tablica, zmienna określonego typu, obiekt określonej klasy), a nie ten powiązany z implementacją (czyli obiekt propela).
Następnie przekazujesz dane do widoku i ten dopiero sobie formatuje dane wyjściowe takie jak XML-RPC. Poczytaj jak działają znane aplikacje typu Facebook i jak wygląda Ich WebAPI.

Huh? Najdziwniejsza definicja MVC jaką słyszałem. Nie wiem, może jest ona popularna w środowiskach akademickich, ale nie o to chodzi.
Nazywać widokiem program, który pobiera dane przez XML-RPC to żenada
Zgadzam się, że można takie 3 warstwy wyodrębnić, ale to nie jest MVC nie w takiej makroperspektywie. Przypomina mi się to co kiedyś napisał Jeff Atwood, jeden z czołowych blogerów IT - porównując poszczególne warstwy do przeglądarki (kontroler), html (model) i stylów CSS (widok).

Ty powinieneś się zająć MVC w samym krypcie PHP - frameworku, którego opracujesz; Choć polecałbym użyć gotowego narzędzia (polecam Agavi, pomógłbym we wdrożeniu się w Nią). To w Nim się skup na MVC, a to czego żąda od ciebie opiekun to właśnie jest widok takiej aplikacji. Widok, któremu dostarczasz danych z modelu (Propel) i poprzez kontroler. Widok, który równie dobrze powinien oferować te dane w innych formatach tj. HTML, JSON, RSS (Atom) etc.

Nie chcę tutaj podważać zdania Twojego promotora, ale się z Nim nie zgadzam - przynajmniej z definicji.

Tzn. opiekun tak napisał ale jak rozmawiałem z nim i w tym mailu tez (bo calego nie skopiowalem) cały czas mówiliśmy o model(baza)-widok(np html)-kontroler(akcje). A mógłbys mi napisac jak wyglada wymiana danych np. od formularza do zapisania danych w bazie w tym Agavi? Czy tam wykorzystane jest wlasnie DTO i xml-rpc? Dokumentacje do tego sobie pozniej przeczytam dokładniej.

Agavi dzieli się na wiele klas o wyspecjalizowanych zadaniach (działa to na zasadzie dependency injection).
Do tego co Ciebie interesuje, mogę zaliczyć obiekt Request. Jest już kilka gotowych w tym SoapRequest i WebRequest, które kolejną są w stanie odebrać żądanie zanalizować i udostępnić w aplikacji - WebRequest robi to najprościej, bo zwyczajnie pobiera dane z GET i POST.
Następnie jest to żądanie mapowane do akcji, która jest uruchamiana, a tam korzystając z modelu (lub bezpośrednio z ORM, nic nie jest wymuszone) pobierasz dane i przesyłasz do widoku. Widoków dla danej akcji może być kilka np Success(użytkownik został dodany), Error (dany post nie istnieje) lub Input (formularz). Dalej widok może posiadać kilka tzw output_types. Sam je sobie definiujesz. Może to być Html (uzywasz szablonów i definiujesz znaczniki) lub Json (widok zwraca zwyczajne json_encode" title="Zobacz w manualu PHP" target="_manual), albo twój XML-RPC (znów możesz szablon, albo napisać swój obiekt Response).

Co do TransferObject. W Javie jest to zserializowany obiekt z danymi przesyłany wewnątrz XML (w np. XML-RPC) - generalnie by zmniejszyć ilośc danych.

oki na razie Dziękuję Ci bardzo za odpowiedzi. Jak coś więcej rusze to odezwę się w tym temacie jeszcze. Pozdr

Wbrew pozorom takie rozwiązanie jest całkiem sensowne. Możliwe nawet, że z czasem coraz więcej aplikacji będzie tworzonych w ten właśnie sposób. Spójrzcie choćby na oprogramowanie Zimbra. Co prawda jest napisana w Javie, ale komunikacja pomiędzy poszczególnymi modułami a bazą danych odbywa się w całości przez SOAP. Również niektóre moduły komunikują się między sobą w ten sposób.
Takie podejście np. uniezależnia programistę od używania konkretnej technologii. Możemy choćby pisać w PHP pluginy do systemu, który pierwotnie był napisany w Javie.
Dla mnie też to było dziwne na początku, ale DTO to w wielu przypadkach naprawdę świetna sprawa

Ale to co przedstawiasz to albo WebAPI albo zwykła opcja bazy (np. już SyBase to posiada).



Nadal WebAPI.



I podsumowując ma się nijak do tego co się chce dowiedzieć @majsterweb - nie odpowiada na żadne pytanie.
Bo i tak za poszczególnymi modułami komunikującymi się poprzez SOAP stoi aplikacja, która jest w stanie przetworzyć żądanie wysłać odpowiedź w odpowiednim formacie i może to być aplikacja napisana proceduralnie, OOP albo MVC.

WebAPI jest szczególnie popularne w czasach Web 2.0 gdzie każdy serwis stara się je udostępnić (patrz Grono.net).


edit:

Co do XML-RPC zauważyłem, że Agavi ma wbudowaną obsługę.

@LBO: Chyba jednak moja odpowiedź ma coś wspólnego z pytaniem, które zadał majsterweb. Podobne podejście do opisywanego znane jest choćby z bardzo popularnej Zimbry. I przekonałem się na własnej skórze, że można w ten sposób łatwo budować aplikację korzystając z wielu języków programowania jednocześnie. Oczywiście jest to WebAPI, ale używane w innym kontekście niż tylko udostępnienie bazy danych serwisu na zewnątrz, czyli do wewnętrznego komunikowania się modułów pojedynczej, spójnej aplikacji.

To może inaczej - kojarzysz Facebooka, prawda?
Stworzyli niesamowite API dzięki któremu można robić wszystko, ale nadal to jest domena Ich frameworka, która działa na poziomie języka w którym jest zaimplementowany.

Bo to co ty piszesz to przytakiwanie @majsterweb, żeby napisał osobna aplikację, która będzie przy pomocy Propela odbierać żądania XML-RPC i wysyłać odpowiedzi. I drugą też w PHP, żeby wykorzystała to API do czegoś tam. Ale po co, niech się skupi na jednym frameworku (czy sam napisze, czy wykorzysta istniejący)...

Pozdrawiam

Uważam, że nie do końca zrozumiałeś intencje profesora z uczelni majsterweba. Ale ok, przyznaję Ci rację. Stwierdzam zatem że jedyne słuszne podejście reprezentujesz Ty, a promotor majsterweba nie zna się na swojej robocie i nie wie co mówi. Trudno, przyroda. Nie mam żadnego interesu w tym, żeby dalej próbować to tłumaczyć, więc z mojej strony EOT.

A może jednak byś spróbował.

Co do profesora - wiem jedno nie każdy jest omnibusem i często jest tak, że sami nie wiedzą o czym mówią. Stara prawda na chyba wszystkich uczelniach.

Nie twierdzę, że jego promotor się nie zna, ale ale... może przeczytaj moje posty na temat jego teorii.

Mi się zdaje, że profesorek miesza MVC z obliczaniem rozproszonym i tu ~LBO ma rację mówiąc o makroperspektywie.
Mamy 3 komputery (serwery)
1. Zawiera logikę (serwer aplikacji)
2. Zawiera widok (serwer www z obsługa php) Jest to coś jak frontend systemu
3. Zawiera dane (serwer z np. mysql)

Komunikacja między 1 i 2 odbywa się za pomocą WEBAPI w standardzie XML-RPC. 1 używa 3 do pobrania danych i je logicznie przetwarza, zwraca do 2 XML'a z wynikami. Ten je wyświetla.

1 i 2 posiadają swoje wewnętrzne mechanizmy - najczęściej oparte o MVC i oba generują widok. Stosuje się do nich te same zasady projektowania co do całego systemu, tylko w mniejszej skali.

Pozdrawiam