kolejny temat w stylu "dobrze rozumuję?" Opcje

[owi]

Coś tam w swoim życiu w php napisałem. Dopóki koncentrowałem się na frontendzie to mi strukturalne programowanie wystarczało (strony dla malych firm nie wymagały bycia alfą i omegą z php). Teraz jednak chcialem się bardziej skoncentrować na php, ogarnąc troszke frameworki więc uznałem, że konieczne będzie poznanie OOP w php.

Przeczytałem pare kursów dziś i wczoraj.
Na razie to mam jeden wielki mętlik. W zasadzie coś juz tam tworze, ale najwazniejsze dla mnie jest zrozumienie logiki.

Czyli załóżmy yyyyy eeeeeee, że chce zrobić powiedzmy system newsowy.

To czy jezeli utworzę:

klasa: newsy
właściwosci :tytul,autor,data, tresc etc
metody: dodaj newsa, usun newsa, edytuj newsa, wyswietl newsa

to czy będzie to poprawne logicznie rozumowanie? Czy to będzie juz oop, czy może już o tej godzinie po takiej ilości tekstu i informacji pierniczę jak potłuczony?
Jak do takiej klasy dolaczyc komentarze? Czy utworzyc sobie analogicznie klasę komentarze z odpowiednimi polami i metodami ( w zasadzie identycznymi) czy jak?


edit:

Teraz jeszcze sobie tak wydumałem, że wyświetlanie newsa mogłoby być oddzielone od samej klasy.hm?

Ten post edytował owi 7.10.2008, 01:58:30

[LBO]

Tak, dobrze rozumujesz.

Radziłbym Tobie poszukać podobnych tematów - jest Ich mnóstwo - Sam pamiętam jeden gdzie sie szeroko o tym wypowiadałem.

Wyswietlanie powinno być oddzielone od samej klasy która trzyma dane. Jest to naturalne i bardzo wygodne podejście. Daje dużą elastyczność.

Jestem przeciwny takim smaczkom (odnosząc się do twojego przykładu) jak:

[PHP] pobierz, plaintext 
<?php
$news = new News(1); // pobieramy news o identyfikatorze id = 1
$news->showAsHTML(); // blee
?>
[PHP] pobierz, plaintext 

lepiej wygląda jak klasa news nie jest tak wyspecjalizowana i zajmuje sie tylko zapisywaniem lub zwracaniem danych:

[PHP] pobierz, plaintext 
//skrypt wyswietlający html
<h2><?php print $news->getTitle(); ?></h2>
<p><?php print $news->getBody(); ?></p>
<span>autor: <?php print $news->getAuthor(); ?></span>
[PHP] pobierz, plaintext 

lub

[PHP] pobierz, plaintext 
<?php
//skrypt wyswietlający JSON
$data = array(
'title' => $news->getTitle(),
'body' => $news->getBody(),
'author' => $news->getAuthor()
)
print json_encode($data);
?>
[PHP] pobierz, plaintext 

Oczywiście to jest uproszczony przykład, po bardziej skomplikowane rozwiązania zapraszam do zapoznania się z którymś z wiądących frameworków Po to są.

[owi]

No rozumiem.

kwestia teraz tego zapisywania zwracania danych. Czy nie lepiej jest powierzyć obsługiwanie newsa klasie newsy, a samo zapisywanie (podobnie jak wyświetlanie) do bazy danych powierzyć jeszcze oddzielnej klasie?

Obiło mi się o uszy o propelu. czy to jest dobra biblioteka do obslugi baz dancyh w niewielkich projektach czy lepiej coś małego swojego stworzyć?

Przepraszam jezeli walkuje jakis temat n-ty raz. nie proszę o zrobienie czegoś za mnie. Proszę tylko o ukeirunkowanie. Reszty sam sie nauczę, bo o to przecież chodzi.

[LBO]

kwestia teraz tego zapisywania zwracania danych. Czy nie lepiej jest powierzyć obsługiwanie newsa klasie newsy, a samo zapisywanie (podobnie jak wyświetlanie) do bazy danych powierzyć jeszcze oddzielnej klasie?

A to zależy już tylko od ciebie - co kraj to obyczaj. Istnieja wzorce etc ale też i one zostawiaja pewną dowolność.

Obiło mi się o uszy o propelu. czy to jest dobra biblioteka do obslugi baz dancyh w niewielkich projektach czy lepiej coś małego swojego stworzyć?

Propel to świetny ORM - poznanie go na pewno zaowocuje w przyszłości.

[plurr]

kwestia teraz tego zapisywania zwracania danych. Czy nie lepiej jest powierzyć obsługiwanie newsa klasie newsy, a samo zapisywanie (podobnie jak wyświetlanie) do bazy danych powierzyć jeszcze oddzielnej klasie?

ogolnie to Twoja klasa powinna tylko 'wydawac' polecenia typu 'saveNews', a juz sam model powinien zajac sie wklepywaniem do bd - daje to pewna elastycznosc kodu, tak dziala wiekszosc frameworkow itp Wszystkie metody sety/gety na bazie napisz sobie w osobnej klasie.

Ten post edytował plurr 9.10.2008, 20:50:20

[f1xer]

generalnie newsy to przykład komponentu na który powinien składać się kontroler model i widok(i) poczytaj o MVC (masa na tym forum)

[LBO]

@f1xer nie wszystko musi koniecznie być oparte o MVC - więc koledze nie mieszaj.

Po za tym jak na dłoni widać, że kolega robi model - nie wspomina nam w jaki sposób będzie to obsługiwać, bo to jest nieistotne - na tym poziomie ważne jest API a nie żróło danych (baza, webservice,...) czy wykorzystana biblioteka (PDO, Zend_Service,...).

Ten post edytował LBO 10.10.2008, 14:45:08

[f1xer]

@LBO masz racje MVC to nie wszystko ale chyba przyznasz że warto w nim pisać. Poza tym sam napisałeś że lepiej żeby oddzielić wyświetlanie od danych więc mamy już tutaj MV brakuje tylko kontrolera. Tyle OT'a pozdrawiam

[owi]

wrzucilem se symfony w wersji sanbox, potem zainstaluje peara bo z cli dziala mi symfony.bat, zas z symfoclipse cos sie pieprzy, pomimo iż rozpoznaje wszystko poprawnie.
Ale nie o to mi chodzi.

Wgralem symfony, żeby na własne oczy nauczyć się poprawnego budowania modelu MVC, nastepnie stworze coś swojego.
DZiekuje wszystkim za rady

[LBO]

wrzucilem se symfony w wersji sanbox, potem zainstaluje peara bo z cli dziala mi symfony.bat, zas z symfoclipse cos sie pieprzy, pomimo iż rozpoznaje wszystko poprawnie.
Ale nie o to mi chodzi.

Wgralem symfony, żeby na własne oczy nauczyć się poprawnego budowania modelu MVC, nastepnie stworze coś swojego.
DZiekuje wszystkim za rady

Zmartwię ciebie, ale Symfony nie posiada poprawnego modelu.

ORM to nie jest model, nie możesz go bezboleśnie wymienić, bądź zupełnie zmienić źródła danych.

[mike]

ORM to nie jest model, nie możesz go bezboleśnie wymienić, bądź zupełnie zmienić źródła danych.

Oczywiście, że można.
Jeśli zapewnisz, że narzędzie, które wstawisz będzie miało ten sam interfejs to możesz sobie podmienić.

Pewnie byłoby to trudne ale da się. Jeżeli by Propela przykryć sfPropelFinderem to możesz przezroczyście dla aplikacji podmienić go na Doctrine'a. Co czyni warstwę modelu prawdziwie abstrakcyjną.

[LBO]

Oczywiście, że można.
Jeśli zapewnisz, że narzędzie, które wstawisz będzie miało ten sam interfejs to możesz sobie podmienić.

Ale jak nie przykrywasz to w tym względzie jesteś w głębokiej ***** i mam rację

Pewnie byłoby to trudne ale da się. Jeżeli by Propela przykryć sfPropelFinderem to możesz przezroczyście dla aplikacji podmienić go na Doctrine'a. Co czyni warstwę modelu prawdziwie abstrakcyjną.

A ja wolę zwykły obiekt i się nie martwię interfejsem bibliotek których używam i Ich integracją, O! Autentycznie moge wybierać pomiędzy silnikami i bazami. Taki PHPowy POJO.
Jest to znacznie bardziej przenośne. Pamiętaj, że i tak każda abstrakcja jest prostsza od tej leżącej pod Nią (bardzo lubię to zdanie) i nic na to nie poradzisz.

Ten post edytował LBO 10.10.2008, 16:54:05

[owi]

koledzy po polsku prosze ;D spokojnie - do takich rzeczy o ktorych tu opowiadacie to mam jeszcze duzo nauki. Jak na start ogarniecie samej obiektówki poprawnie plus symfony plus nowe narzedzie jakim jest eclipse da mi wrazen i roboty na dlugie tygodnie

[Sedziwoj]

@owi
Na razie zignoruj ich dyskusję

A co do warstwy modelu, to jednak byłbym za tym co pisze LBO, co prawda sam siedzę jak w Symfony na Propel, ale nie znaczy że to jest najlepsze wyjście. Po prostu można by było dać warstwę do której się odwołują akcje, a w tej warstwie dopiero było by tłumaczone to na Propel/Doctrine/PDO czy kto tam sobie życzy, dodać fabrykę do takiej warstwy i można się bawić zamieniając używać różnych ORM i nie tylko bez interwencji w kod akcji. Tylko to wymaga dodatkowego czasu interfejsów itd. więc pytanie czy warty jest ten dodatkowy wkład czasowy i obliczeniowy?

[LBO]

@Sedzowuj, opłaca się Miałem wymuszoną okazję zmieniać Propela na czyste PDO w ten sposób. Bezbolesne.

edit:

A ja sie zastanawiam jak do ORMów, ARów, DAOów odnoszą się projekty informatyczne, które korzystają ze specyfikacji (diagramy UML). Bo załóżmy, że projektanci stworzyli zestawy klas i chyba źle by było je zignorować (piszę w kontekście MVC) i działać bezpośrednio na np. Propelu. Wydaje mi się, że właśnie wtedy tworzymy modele o których pisałem wcześniej. Trzymające i opisujące logikę biznesową niezależne od źródła danych.

Może ma ktoś doświadczenie w tym względzie?

Ten post edytował LBO 20.10.2008, 08:39:45