Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

4 Stron V  < 1 2 3 4 >  
Reply to this topicStart new topic
> ActiveRecord, ORM
Yacho
post 14.05.2007, 18:00:11
Post #21





Grupa: Zarejestrowani
Postów: 148
Pomógł: 0
Dołączył: 16.06.2003

Ostrzeżenie: (0%)
-----


Cytat(athabus @ 19.03.2007, 15:02:56 ) *
Trzecia sprawa to to, że początkowy zysk w postaci szybszego kodowania jest opłacony przez mniejszą przejrzystość kodu w przyszłości.

No cos ty - to wyobraz sobie co sie dzieje w momencie kiedy masz aplikacje napisana z palca - i masz jakies 200 roznych SQL query - i klient jest bardzo przesądny i naprzyklad nie podoba mu sie pole czarny_kot w bazie danych - musisz zmienic 200 zapytań - w propelu jeden tag XML i działasz... winksmiley.jpg

pozatym myślę ze idea AR i ORM jest inna niż wszyscy myśla tu - klasy ORM sa po to aby juz enkapsulować jakąs logike biznesowa - powstały po to aby zintegrowac warste funkcjonalności biznesowych z dotyczacych tych danych. obiekt ORM jest po to zeby zdefiniowac także akcje jakie z obiektem sa powiazane, jest gdzies pomiedzy warstwa danych a biznesowa - natomiast nie ma watpliwosci ze AR jest tylko do ujednolicenia dostepu do bazy - na mniejszym stopniu abstrakcji niż ORM ale znacznie wiekszym niz bawienie sie w zapytania...


--------------------
-=Yacho=-

nospor -> trzymaj sie i nie dajcie sie !
Go to the top of the page
+Quote Post
athabus
post 14.05.2007, 21:27:35
Post #22





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Yacho nie dość, że cytujesz moją wypowiedź sprzed 2 miesięcy, to jeszcze była ona na temat AR a nie ORM tongue.gif

Tak jak tam pisałem odnosiłem się do AR na przykładzie ZF, z którym miałem okazję spędzić trochę czasu. Problem jak się tu pojawił to, to że w momencie zmiany nazwy pola w tabeli musiałbym poprawić wszystkie odwołania, które korzystały z tej tabeli - także akurat Twój przykład tutaj nie za bardzo był trafny.

Pod wpływem tego wątku zainteresowałem się ORM (konkretnie Propelem) o czym też zresztą pisałem już w tym wątku tongue.gif Powiem szczerze, że jestem pozytywnie zaskoczony tym rozwiązaniem - nie myślałem, że w PHP uda się takie coś popełnić. Właśnie kończę pierwszy projekt z wykorzystaniem Propel'a i to jest coś czego mi od dawna brakowało.

Co do ORM to nie podoba mi się przekonanie, że są one bez sensu bo przy skomplikowanych zapytaniach wykonują nieoptymalne operacje i są be. Wiadomo, że jeśli robisz joina po wielu tabelach, czy wykonujesz jakieś skomplikowane zapytanie, to automatix nie jest najlepszym wyjściem - ORM ułatwia korzystanie z bazy, ale nie zdejmuje z programisty konieczności myślenie i optymalizacji. Po prostu są rzeczy, które można zostawić Propelowi do zrobienia i są takie w których trzeba mu trochę pomóc.
W propelu podoba mi się to, że przewidziano możliwość własnego konstruowania zapytań czy dodawania logiki do klasy. Programowanie z Propelem to jest po prostu bajka.
Go to the top of the page
+Quote Post
Sokal
post 23.05.2007, 17:57:58
Post #23





Grupa: Zarejestrowani
Postów: 237
Pomógł: 1
Dołączył: 8.02.2007

Ostrzeżenie: (10%)
X----


Myślę sobie teraz o ORM...

Według mnie jest to utrudnianie sobie życia. Chyba lepiej poznać SQL niż uczyć się metod, które działają tak samo jak polecenia w SQL-u... Argument? Mamy jakieś złożone zapytanie, przy pomocy takiego ActiveRecords tego nie zrobimy. No i co? Musimy się uczyć SQL-a lub szukać po internecie jak coś zrobić. A nie lepiej od razu poznać go? Aplikacja działa szybciej, bo nie odpala iluś tam metod zanim wykona zapytanie.

IMHO ORM jest ułatwieniem dla początkujących winksmiley.jpg

Ten post edytował Sokal 23.05.2007, 17:58:15


--------------------
Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
Go to the top of the page
+Quote Post
menic
post 23.05.2007, 18:05:32
Post #24





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


Jestes w błedzie Misiu (a moze pingwinku;) )
Złozone zapytania? Ich raczej czesto nie piszemy.


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post
Sokal
post 23.05.2007, 18:11:20
Post #25





Grupa: Zarejestrowani
Postów: 237
Pomógł: 1
Dołączył: 8.02.2007

Ostrzeżenie: (10%)
X----


A co powiesz na to, że piszesz jakąś super złożoną aplikację. W bazie trudno się połapać a złożone zapytania to są co drugą linijkę w kodzie.

Nie zrobisz tego przy użyciu, np. activerecords. Co prawda masz tam metodę query(), ale jak jest activerecords to po co taka metoda? snitch.gif Skoro: złożone zapytania => "Ich raczej czesto nie piszemy."...

Według mnie lepiej korzystać np. z PDO winksmiley.jpg

// I jeszcze jeden argument:
Przez ORM kod aplikacji się wydłuża

Ten post edytował Sokal 23.05.2007, 18:12:27


--------------------
Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
Go to the top of the page
+Quote Post
bela
post 23.05.2007, 19:22:15
Post #26


Administrator PHPedia.pl


Grupa: Developerzy
Postów: 1 102
Pomógł: 2
Dołączył: 14.09.2003

Ostrzeżenie: (0%)
-----


Cytat
// I jeszcze jeden argument:
Przez ORM kod aplikacji się wydłuża

kod? no prosze.

  1. <?php
  2. $news = NewsPeer::doSelect(new Criteria()); 
  3. ?>

jest dluzsze od selecta w sqlu?

poza tym, orm sprawia kod bardziej czytelnym

co do zlozonych zapytan, ja czesto ich nie uzywam, czasem zdarzaja sie join na dwoch poziomach, ktorych niestety propel jeszcze nie obsluguje. ale miejmy nadzieje ze propel 2.0 bedzie niebawem smile.gif


--------------------
Go to the top of the page
+Quote Post
menic
post 23.05.2007, 19:31:18
Post #27





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


No to zaczynamy:
Sam AR moze i jest trudniejszy i bez sensu przy PDO, ale juz odpowiednio zbudowany ORM to juz inna bajka. Przyklady beda sie opierac na moim skrypcie. Dodatko do pelni szczescia potrzebne jest np. PHPIDE aby ladnie podpowiadalo metody obiektu snitch.gif Zacznijmy od tego ze strukture bazy danych definiujemy podobnie jak w propelu w xmlu. Na podstawie tego sa generowane odpowiednie klasy modelu. Najpierw "tworzymy" zapytanie
  1. <?php
  2. $oNews = new NewsModel();
  3. $oNews->addWhere( NewsModel::CAT_ID, swRequest::Get( 'id' ) );
  4. $oNews->addJoin( NewsModel::AUTHOR_ID, UsersModel::ID, 'LEFT' );
  5. $oNews->addJoin( NewsModel::CAT_ID, News_categoriesModel::ID, 'LEFT' );
  6. $aNews = $oNews->selectJoin();
  7. ?>

Mamy juz pobrane dane do $aNews. Wpisujujac $aNews-> otrzymujemy z podpowiedzi cala liste dostepych kolumn. Bo kazda kolumna ma metode getKolumna(). Dodatkowo dla dolaczonych tablel najpierw $aNews->joinJakasKolumna()->jakasKolumna() Oczywiscie wszystkie metody podpowiada nam eclipse. Tak by wygladala sprawa z pobieraniem danych. Przejdzmy teraz moze do ich dodawania snitch.gif
  1. <?php
  2. $oNews = new NewsModel();
  3. $oNews->setAuthor_id( 1 );
  4. $oNews->setCat_id( swRequest::Post( 'news_categories_id' ) );
  5. $oNews->setContent( swRequest::Post( 'content' ) );
  6. $oNews->setCREATED_AT( time() );
  7. $oNews->setTitle( swRequest::Post( 'title' ) );
  8. $oNews->insert();
  9. ?>
No i znowu tutaj kazda metoda odpowiada kolumnie w bazie danych. Dodatkowo mamy tutaj filtrowanie danych, tak wiec nie wstawimy jakiegos stringa do kolumny ktora oczekuja liczbe. I powiedz mi ze to jest niewygodne to cie normalnie nie wiem co tongue.gif


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post
Sokal
post 23.05.2007, 20:04:59
Post #28





Grupa: Zarejestrowani
Postów: 237
Pomógł: 1
Dołączył: 8.02.2007

Ostrzeżenie: (10%)
X----


Dla mnie to zawsze będzie niewygnodne, co z tego, że podpowiada mi składnie...

Więcej czasu zabiera wykonywanie zapytań winksmiley.jpg


--------------------
Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
Go to the top of the page
+Quote Post
menic
post 23.05.2007, 20:07:08
Post #29





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


Co z tego? Np. to ze nie musisz pamietac nazw wszystkich tabel ani kolumn w bazie danych. To ze masz wieksza kontrole. To ze jest wygdniej tongue.gif Dorosniesz to zrozumiesz (joke) winksmiley.jpg


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post
webik
post 24.05.2007, 00:19:43
Post #30





Grupa: Zarejestrowani
Postów: 24
Pomógł: 0
Dołączył: 1.05.2006
Skąd: Leżajsk\Kraków

Ostrzeżenie: (0%)
-----


Witam

Ot dorzuce swoje 3 grosze.... Osobiście używam PEAR DB_DataObject... Bardzo mnie sie podoba mialem troch problemów tyczącyc sie pierwszegoo uruchomienia i pierwszego utworzenia klas odwzorowujacych tabele.... Ale teraz wszystko idzie gładko..... Wszystko tworzy sie automatycznie pozniej tylko wykorzystuje klasy... Do tej pory nie zauważylem nadmiaru zapytań chciaż czasem jestem zbyt wyrozumiały wobec ilośici zapytań generowanych przez moj kod... Wczećniej uzywałem ADOdb i teraz wydaje mnie sie ze teraz ograniczyłem liczbe zapytań.... Kod też staje sie bardziej przejżysty ot chodźby pobranie usera:

  1. <?php
  2. //$id = primary key;
  3. $user = DB_DataObject::factory('users_desc');
  4. $user->get($id);
  5. ?>


i w objekcie user mam odrazu wszystko, warunki nie ma problemu:

  1. <?php
  2. $user = DB_DataObject::factory('users_desc');
  3. $user->id = $id;
  4. $user->online = 1;
  5. $user->find();
  6. ?>


cala struktura klasy na podstawie bazy jest przygotowywana z pommocą skryptu.... wiec zero pracy do wykonania... No chyba że chcemy jekies specjalne warunki przy dodawaniu do bazy... validatory nie napisza sie same....

wydaje mnie sie proste i przyjemne...

Ale moze to tylko przyzwyczajenie....

Pozdrawiam


--------------------
Errare humanum est
Go to the top of the page
+Quote Post
mike
post 24.05.2007, 11:52:32
Post #31





Grupa: Przyjaciele php.pl
Postów: 7 494
Pomógł: 302
Dołączył: 31.03.2004

Ostrzeżenie: (0%)
-----


~Sokal a dlaczego uważasz że ORM jest dla osób nie znających SQL'a?
Tak się składa że jest dokładnie odwrotnie. Nie podejdziesz do żadnego ORM'a nie mając solidnych podstaw i wiedzy o SQL.

"IMHO ORM jest ułatwieniem dla początkujących winksmiley.jpg" - to Twoja opinia. A praktyka pokazuje że żaden większy bądź duży projekt nie jest pisany bez ORM'a
Już pomijam PHP, w Java na przykład większość aplikacji śmiga na Hibernate.
Go to the top of the page
+Quote Post
splatch
post 24.05.2007, 12:04:35
Post #32





Grupa: Zarejestrowani
Postów: 487
Pomógł: 7
Dołączył: 7.01.2004
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Cytat(Sokal @ 23.05.2007, 21:04:59 ) *
Dla mnie to zawsze będzie niewygnodne, co z tego, że podpowiada mi składnie...

Więcej czasu zabiera wykonywanie zapytań winksmiley.jpg

To po cholerę tu siedzisz, pytam? To forum to niby PRO więc się nie zachowuj jak dziecko i nie strzelaj fochów, że coś Ci się nie podoba i basta. Po cholerę wcinałeś się do tego wątku, tylko po to, żeby pokazać swoje wstecznictwo i ciemnotę? Jeśli nie masz więcej argumentów przeciw to, proszę, zamknij się i nie wtrącaj z byle gównem.

Ps. Jestem za usunięciem postów-śmieci z tego wątku (w tym i mojego).


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
athabus
post 26.05.2007, 18:27:32
Post #33





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


splatch ty jakiś agresywny ostatnio jesteś blink.gif

Sokal - ORM nie jest po to aby nie uczyć się SQL. Ideą (tak mi się przynajmniej wydaje) to zdjęcie z programisty powtarzania ciągle tych samych operacji na bazie danych. Ciagłego pisania banalnych selectów itd. W PHP w porównaniu z innymi językami duży procent rzeczy, które robisz są "banalne", dlatego, że nie ma narzędzi automatyzujących pracę, albo mało osób z nich korzysta.

Powiem szczerze, że czasami jak pisze jakąś prostą stronkę to już mi się chce za przeproszeniem rzygać jak muszę napisać kolejny obiekt DAO, który w zasadzie robi to samo co inne tylko ma trochę inne nazwy pól itp. Dzięki Propelowi, frameworkom itd itp możesz skupić się na tych bardzie zawiłych rzeczach, a te rutynowe zostawiasz odpowiedniemu narzędziu.

Co do tego, że ORM jest dla osób nie znających SQL to mam takie zdanie jak Mike - żeby napisać dobrze coś w ORM trzeba na prawdę orientować się jak działa SQL i w ogóle baza danych. Trzeba wiedzieć, kiedy użyć gotowych rozwiązań ORM, a kiedy warto rozszerzyć daną klasę np. o pobieranie kolekcji nietypowych elementów.

Przykład z życia - masz sklep internetowy w którym produkty przynależą do różnych kategorii, mają różne stawki vat, marki, cechy. Liczba cech produktu jest zmienna. Każdy produkt ma różne progi rabatowe itd itp. Stajesz przed zadaniem pobrania x produktów z bazy z pełną informacją (czyli dodatkowe cechy, progi rabatowe itd). Gdybyś tutaj użył ORM'a bez własnej inwencji to położyłbyś bazę na łopatki ilością zapytań. Pół dnia zajęło mi, aby to zoptymalizować, napisać własne metody pobierania i wypełniania obiektów itd. Ale skutek jest taki, że dowolną ilość obiektów z bazy pobieram 2 zapytaniami Wcześniej jednak musiałem użyć tabel przejściowych, trochę cachowania itd. Mechanizmy Propela pozwoliły mi przebrnąć przez całe zadanie w miarę wygodnie - ale na pewno nie rozwiązały same mojego problemu - po prostu były punktem wyjścia. Swoją drogą było to fajne doświadczenie, bo rozwiązując kolejne problemy przejrzałem kod propela wzdłuż i wszerz - pewne rzeczy wydawały mi się na początku dziwne, ale potem często zauważałem ich uniwersalność i możliwość dostosowania całego narzędzia do swoich potrzeb.
Go to the top of the page
+Quote Post
eai
post 31.05.2007, 14:10:14
Post #34





Grupa: Zarejestrowani
Postów: 367
Pomógł: 10
Dołączył: 20.05.2005

Ostrzeżenie: (0%)
-----


Nie ukrywam, temat dość ciekawy.
Nie wiem jednak czy dobrze to zrozumiałem, a nie chce tkwić w błędzie dlatego napisałem:
  1. <?php
  2.  
  3. class Query
  4. {
  5.  public static function Exec ($sql)
  6.  {
  7. if(mysql_connect('localhost','root', 'idesql'))
  8. {
  9.  if(mysql_select_db('test'))
  10.  {
  11.  return new ORM(mysql_query($sql));
  12. }
  13. }
  14. }
  15. }
  16.  
  17. class ORM
  18. {
  19.  private $__dquery = array();
  20.  
  21.  public function __construct($query)
  22.  {
  23.  $this->__dquery = $query;
  24. }
  25.  
  26.  public function select()
  27.  {
  28. if($array = mysql_fetch_assoc($this->__dquery))
  29. {
  30.  return new Data($array);
  31. }
  32.  
  33. return false;
  34. }
  35. }
  36.  
  37. class Data
  38. {
  39.  private $__darray = array();
  40.  
  41.  public function __get($name)
  42.  {
  43. if(empty($this->__darray)) { return false; }
  44.  
  45.  if(array_key_exists($name, $this->__darray))
  46.  {
  47. return $this->__darray[$name];
  48.  }
  49. }
  50.  
  51.  public function __construct($array)
  52.  {
  53.  $this->__darray = $array;
  54. }
  55. }
  56.  
  57.  
  58.  
  59. $table = Query::Exec('SELECT * FROM `tabela`');
  60.  
  61. while($row = $table->select()) {
  62. echo $row->nr . '; ';
  63. echo $row->imie . '; ';
  64. echo $row->nazwisko . ' <br>';
  65. }
  66.  
  67.  
  68. ?>


Jest to oczywiście bardzo prosty przykład, posiadający jedynie możliwośc pobierania wyników.

Moje pytanie brzmi: Czy ide w dobrym kierunku czy kompletnie nie zrozumiałem ORM?
Go to the top of the page
+Quote Post
splatch
post 31.05.2007, 17:40:38
Post #35





Grupa: Zarejestrowani
Postów: 487
Pomógł: 7
Dołączył: 7.01.2004
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Cytat(eai @ 31.05.2007, 15:10:14 ) *
Moje pytanie brzmi: Czy idę w dobrym kierunku czy kompletnie nie zrozumiałem ORM?


Idziesz w prawie dobrym kierunku. smile.gif
Ideą stosowania mapowań jest wykluczenie klepania SQLa na każdą potrzebę, a w tym momencie, mimo tego, że wynik masz reprezentowany w postaci obiektu, a nie różni się to od:
  1. <?php
  2. $rs = mysql_query($sql);
  3. while ($row = mysql_fetch_object($rs)) {
  4. echo $rs->id .' '. $rs->name .'<br />';
  5. }
  6. ?>


Owszem, umiejętność interpretacji każdego zapytania to cenna funkcjonalność, ale nie zapominaj o tym, że zależy Ci na obiektach jako takich a nie płaskich strukturach pokroju tablicy, a taki efekt uzyskujesz korzystając z __get (zwracasz po prostu kolumnę z wyniku nie zwracając uwagi na to z jakiego obiektu to jest property). Zwróć uwagę, że tu nie ma obiektu. Nie możesz odczytanych wartości zmodyfikować i zapisać.
Obiekt Query może się przydać przy mapowaniu zapytań, ale raczej nie przy ich interpretowaniu.

Kilka przykładów użycia "klasycznego" ORM:
  1. <?php
  2. // Użycie sesji, na podobę Hibernate
  3. // zauważ, że relacje są przeźroczyste
  4. $factory = SessionFactory::build(new PropertiesConfiguration('php-hibernate.ini'));
  5. $session = $factory->getSession();
  6.  
  7. $book = $session->load('Book', 11);
  8. $authors = $book->getAuthors(); // tutaj oczekujemy złączenia po relacji M:N
  9. $book->setTitle('[nakład wyczerpany]' . $book->getTitle());
  10. $book->setAvailable(false);
  11. $authros[0] = new Author('Stanisław', 'Lem');
  12.  
  13. $session->flush(); // wymuszamy zapisanie zmian
  14.  
  15. // uproszczony przykład użycia Table Data Gateway + Row Data Gateway
  16. // relacje M:N są obsługiwane ręcznie
  17. $book = BooksPeer::retrieveByPk(11);
  18. $authors = $book->getAuthors();
  19. $book->setTitle('[nakład wyczerpany]' . $book->getTitle());
  20. $book->setAvailable(false);
  21. // dobieramy się do tabelki pośredniej pomiędzy autorami a książkami
  22. $authros[0]->getProxyForBook(11)->delete();
  23. $authros[0] = new Author('Stanisław', 'Lem');
  24.  
  25. $authros[0]->createProxyForBook(11); // przywiązujemy autora do książki
  26. $book[0]->save(); // ten zapis załatwia nam wszystko
  27. ?>


Pamiętaj, że różnice implementacji przy różnych ORMach są czasami olbrzymie, zawsze możesz znaleźć swoją własną implementację bazując na dostępnych wzorcach.


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
nasty
post 2.06.2007, 13:28:42
Post #36





Grupa: Zarejestrowani
Postów: 634
Pomógł: 14
Dołączył: 27.05.2006
Skąd: Berlin

Ostrzeżenie: (0%)
-----


Witam,
Chciałbym się odnieść do wypowiedzi paru osób które uważają ze ORM-y to tylko ułatwienie dla programisty, i ze jest ucieczka od nauki SQL-a.

Najważniejszą idea systemów ORM jest wspomaganie idei Domain-Driven-Develpment (DDD) która przeważnie jest podzielona na warstwy takich jak:
  • Business Layer
    • Business Entities
      Warstwa/część odpowiadająca za reprezentacje obiektów systemu (Entities) w postaci obiektow POJO/POCO/PO[x]O/etc... jak np. Customer, Book, Author...
    • Business Logic
      Warstwa ta odpowiada za operacje na wspomnianych Entities. I tu ORM-y sa bardzo przydatne, gdyż warstwa ta powinna być niezależną od warstwy dostępu do danych ale mieć w tym samym czasie możliwość operowania na danych zawartych w wspomnianych Entities. Klasy w tej warstwie komunikują się z baza za pomocą innych klas które są w warstwie Data Access Layer.
  • Data Access Layer
    Tu sa klasy DAO, ktore za pomoca ORM-a wypelniaja objekty z warstwy Business Enties odpowiednimi danymi.
Używając tradycyjnych metod dostępu do danych byłoby bardzo ciężko dobrze wymodelować warstwę logiki biznesowej bo np. powiedzmy ze Książka może dostać zniżkę tylko w wypadku kiedy jest kupowana w ilości x/miesiąc oraz ma Dostawce który jest na liście stabilnych dostawców. W tym przypadku używając reprezentacji danych w postaci obiektów, łatwo jest wymusić taka logikę na aplikacji na wiele sposobów takich jak używanie systemu workflow.

Drugim bardzo ważnym argumentem przemawiającym za ORM-ami jest zasada DRY (Don't Repeat Yourself). gdyż obiekty z Business Entities nierzadko biorą udział w Service Layer czyli w warstwie odpowiedzialna za eksponowanie funkcjonalności aplikacji za pośrednictwem Web Services. Używając SQL-a i tak byś musiał operować na obiektach by móc reprezentować dane w wspomnianej Service Layer, tak wiec musiałbyś najpierw wyciągać dane z tych obiektów, następnie zapisywać do bazy SQL-em a w razie potrzeby znowu wyciągać te dane sql-em i zapisywać do obiektów. UI tez czesto uzywa Business Entities...

I jeszcze jedno: używając systemu ORM, możemy wymusić walidacje danych z poziomu samych obiektów poprzez umieszczanie logiki walidacyjnej w setter-ach. W przypadku SQL-a byłoby kilka if() else() przed zapisem.

Dla tych którzy maja bardzo duże wątpliwości co do ORM-ow zalecam przyjrzenie się bardziej dojrzałym produktom takim jak (N)Hibernate, gdzie to ORM może zapisywać dane do prywatnych pól, które są i tak nie eksponowane przez obiekt a wykorzystywane w operacjach logicznych.

Pozdrawiam
Go to the top of the page
+Quote Post
Sokal
post 12.06.2007, 17:33:19
Post #37





Grupa: Zarejestrowani
Postów: 237
Pomógł: 1
Dołączył: 8.02.2007

Ostrzeżenie: (10%)
X----


Chyba mnie przekonaliście do ORM-a winksmiley.jpg
Propel jest zajebiaszczo prosty w obsłudze, a możliwości są wielkie.
Miałem po prostu złe doświadczenia z ORM'em po poznaniu CodeIgniter'a. A kiedy chciałem poznać Propel to miałem same problemy, a to nie ma rozrzerzenia PHP - xslt (które było) a to co innego ...

W piątek spróbowałem jeszcze raz, a wcześniej jakiś tydzień temu w Symfony. Wszystko działa super smile.gif

//
Za moje poprzednie posty przepraszam.

Ten post edytował Sokal 12.06.2007, 17:57:50


--------------------
Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
Go to the top of the page
+Quote Post
Martio
post 6.07.2007, 01:05:47
Post #38





Grupa: Zablokowani
Postów: 167
Pomógł: 2
Dołączył: 15.02.2004

Ostrzeżenie: (30%)
XX---


Jakie znacie lub macie u siebie zaimplementowane sposoby rozwiązania problemu z relacjami pomiędzy tabelami? Jak rozwiązujecie konieczność pobrania danych z bazy danych przy złożonym warunków opierającym się o dwie tablice?
Go to the top of the page
+Quote Post
SongoQ
post 6.07.2007, 01:15:01
Post #39





Grupa: Przyjaciele php.pl
Postów: 2 923
Pomógł: 9
Dołączył: 25.10.2004
Skąd: Rzeszów - studia / Warszawa - praca

Ostrzeżenie: (0%)
-----


Takie cos jest w ORMach zaimplementowane. Patrz np propel http://propel.phpdb.org/trac/wiki/Users/Do...3/Relationships


--------------------
Go to the top of the page
+Quote Post
NuLL
post 6.07.2007, 01:17:38
Post #40





Grupa: Zarejestrowani
Postów: 2 262
Pomógł: 21
Dołączył: 3.05.2004
Skąd: Sopot, Krakow, W-wa

Ostrzeżenie: (0%)
-----


lub w phpDoctrine smile.gif


--------------------
Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
Go to the top of the page
+Quote Post

4 Stron V  < 1 2 3 4 >
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 03:18