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
splatch
post 6.07.2007, 07:48:08
Post #41





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

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


Cytat(splatch @ 31.05.2007, 18:40:38 ) *
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.


Wystarczy zajrzeć pod wspomniany adres..

Data Source Architectural Patterns Table Data Gateway, Row Data Gateway, Active Record, Data Mapper.
Object-Relational Structural Patterns Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance, Inheritance Mappers.
Object-Relational Metadata Mapping Patterns Metadata Mapping, Query Object, Repository.


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
g00fy
post 21.07.2007, 23:55:44
Post #42





Grupa: Zarejestrowani
Postów: 22
Pomógł: 0
Dołączył: 23.11.2004

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


Cytat(cicik @ 27.04.2007, 08:15:45 ) *
Mnie przed ORMami odstrasza jedna rzecz.
Jeżeli mam powiedzmy użytkownika, który należy do jakiejś grupy.
I teraz chce dostać jego imię, nazwisko i nazwę grupy do której należy to w przybliżeniu musiałbym zrobić coś takiego:

$user = new User($id);
$group = $user->getGroup();

Co powoduje wykonanie dwóch selectów zamiast jednego używającego złączenia tabel.
Poza tym wszędzie gdzie czytam o ORMach to zawsze podawany jest przykład taki jak powyżej, który ma być uzasadnieniem tego, że to jest fajne.
Ale co w sytuacjach kiedy potrzebuję mieć zapytanie z kilkoma złączeniami, limitem, sortowaniem, funkcjami specjalnymi typu CONCAT, funkcjami agregującymi itp? Mam wtedy dla takiego zapytania zrobić perspektywę i użyć wzorca Active Record do opisania tej perspektywy? Niby tak można ale wtedy w bazie będę miał 10 razy więcej perspektyw niż tabel...


ormy obsluguja transakcje,rozne rodzaje fetchingu etc... btw , zawsze mozesz zrobc RAW SQL jesli jakies zapytania przez orm robia sie bardzo uciazliwe..
Go to the top of the page
+Quote Post
XvZOK
post 30.07.2007, 15:53:15
Post #43





Grupa: Zarejestrowani
Postów: 5
Pomógł: 0
Dołączył: 30.07.2007

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


A jak Propel radzi sobie z dziedziczeniem w klasach ?

Przykladowo mam klase
Contractor i dziedziczy po niej Client oraz Supplier

Dostawca i klient maja wiele wspolnych pol wiec warto by bylo
zastosowac tu relacje 1-1.
W efekcie mamy 3 klasy w tym 2 dziedziczace i odpowiadajace im tabele.

O ile nie ma problemu z np.: wstawieniem listy transakcji
do klienta (ralacje 1-n) to nie wiem czy propel
poradzi sobie w sytuacji kiedy to 1 klasa bedzie de facto zapisywac do 2 tabel ?

Jakies doswiadczenia w tym temacie ?
Moze inne ORM niz propel ?




2 temat to kwestja konwersji UML do schematu bazy danych.
Googluje juz od kilku dni ale jedyne co znalazlem to MetaL.
Nie dziala on jednak rewelacyjnie i konwertuje to swojego formatu a nie do schema.xml znanego z propela.
Go to the top of the page
+Quote Post
Sedziwoj
post 31.07.2007, 18:56:32
Post #44





Grupa: Zarejestrowani
Postów: 793
Pomógł: 32
Dołączył: 23.11.2006
Skąd: Warszawa

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


Cytat(XvZOK @ 30.07.2007, 16:53:15 ) *
2 temat to kwestja konwersji UML do schematu bazy danych.
Googluje juz od kilku dni ale jedyne co znalazlem to MetaL.
Nie dziala on jednak rewelacyjnie i konwertuje to swojego formatu a nie do schema.xml znanego z propela.

A może coś opisanego tutaj ?


--------------------
Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami.
Go to the top of the page
+Quote Post
splatch
post 31.07.2007, 20:14:53
Post #45





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

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


Cytat(XvZOK @ 30.07.2007, 16:53:15 ) *
A jak Propel radzi sobie z dziedziczeniem w klasach ?

Propel radzi sobie z dziedziczeniem w klasach, aczkolwiek nie jest to "wypasiona" opcja.

Gdyby nazywać to zgodnie z nomenklaturą jest to dziedziczenie zorganizowane na jednej tabeli z dyskryminatorem, czyli kolumną której wartości wskazują z czym mamy do czynienia. Opis wraz z diagramem UML - Single Table Inheritance.
Dokumentacja Propela:
Advanced Object Model.

Przykładowy kod:
Kod
            Client
         /         \
    Enterprise       PrivateClient
                       \
                      CompanyWorker



  1. <table name="client" abstract="true">
  2. <column name="client_type" type="INTEGER" inheritance="single">
  3.   <inheritance key="0" class="PrivateClient" extends="nazwabazydanych.Client"/>
  4.   <inheritance key="1" class="CompanyWorker" extends="nazwabazydanych.PrivateClient"/>
  5.   <inheritance key="2" class="EnterpriseClient" extends="nazwabazydanych.Client"/>
  6. </column>
  7. <column name="title" type="VARCHAR" size="100"/>
  8. </table>


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
XvZOK
post 27.11.2007, 00:15:41
Post #46





Grupa: Zarejestrowani
Postów: 5
Pomógł: 0
Dołączył: 30.07.2007

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


Ponownie wróciłem do tematu.
Widzę, że tutaj nie za dużo się wydarzyło.

Ostatnio zrobilem release tematu podczas tworzenia
abstrakcyjnego kontrolera CRUD do ZF.
Dziwi mnie fakt ze podczas dyskusji o ORM
nikt nie wspomniał o wygodzie przy tworzeniu warstwy widoku.

Przykładowo bibloteka patForms potrafi na podstawie obj. propela
wygenerować nam formularz do wpisywania/edycji danych.
Możemy oczywiście go dowolnie edytować w pliku XML.

Obecnie stosuje zestaw Zend Framework + Propel + Smarty.
Zastanawiam się jednak nad PEAR::DBObject

Testowaliście obydwa pod względem wydajności, wygody użycia ?

Wspomnę jeszcze o DataGrid.
Co polecacie ? Propel dostarcza niby klasę pozwalającą na
integrację z DataGrid z PEAR ale od razu mówie.. wersja jest przestarzała
i lepiej wogóle jej nie ruszać. Ja straciłem 3 h, poznałem dokładnie budowę
DataGrid iw końcu napisałem prawie od nowa klasę integrującą.
Ale teraz efekt jest bardzo przyjemny.
Go to the top of the page
+Quote Post
athabus
post 27.11.2007, 10:59:33
Post #47





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

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


Myślę, że o widoku nikt nie wspomniał, bo temat nie dotyczy widoku :-)

A tak na serio to jeśli już mówimy o wygodzie projektowania aplikacji działających w oparciu o ORM to dla mnie nic nie przebije generacji paneli administracyjnych w symfony

filmik

Kilka linii w pliku konfiguracyjnym i masz wszystko - przeglądanie, dodawanie danych, walidację danych, łączenie danych z wielu tabel po kluczach obcych itd itp.
Jak to pierwszy raz zobaczyłem to się popłakałem, że tyle czasu traciłem na takie bzdety ;-) Zwykły crud to przy tym zabawka.

Inny przykład też z symfony to umieszczenie danych testowych w tabeli z pliku yml - piękna sprawa przy robieniu pierwszych testów.
Go to the top of the page
+Quote Post
splatch
post 27.11.2007, 11:55:44
Post #48





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

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


Kwestia ORM i widoku nie wiąże się pośrednio, ponieważ kluczowe są tu metadane i informacje o strukturach z których ORM korzysta.
Propel ułatwia nam zadanie ponieważ mamy wygenerowany kod z informacjami na temat powiązań itp (bodajże katalog metadata obok innych wygenerowanych klas).
W przypadku ActiveRecord informacje te są zapisane jako fragment definicji w modelu (has_many, many_to_many itp).

Wystarczy zatem bezpośrednio podpiąć się pod metadane i umiejętnie je wykorzystać a nie będziemy potrzebowali generatorów.

Kiedyś dawno, dawno temu dopisywałem adaptery wiążące Propel-Agavi-Smarty tak by tworzyć nowe widoki i wyszukiwarki możliwie łatwo. Dodatkowo powiązałem sobie etykiety z klas z i18n, przez co przy polach wyszukiwania nie musiałem męczyć się z dorzucaniem labeli. Robiły to za mnie po prostu pluginy dopisane do smarty.
Kod, który nie jest wierną kopią tego co napisałem aczkolwiek prezentuje zbliżoną funkcjonalność.
  1. {search for='NazwaKlasy' action=jakiś_url}
  2.  
  3. {field for=id} <- pole z mo&#380;liwo&#347;ci&#261; wpisania tylko intów
  4.  
  5. {field for=foreign} <- tu mi si&#281; pokazywa&#322; np select
  6.  
  7. {field for=someDate fromTo=true} <- a tu para data od, data do
  8. {/search}


Dodatkowym elementem, który sobie wytworzyłem było wiązanie np inputów z wartościami niektórych pól. Dzięki temu nie trzeba podawać atrybutu value, id i tak dalej, ponieważ wszystko to można wyciągnąć dynamicznie z requestu w samym pluginie.
  1. {input for=text}


Po stronie PHP dodałem jeszcze element który nazwałem, może niezbyt trafnie, wrapperem. Jego użycie było bardzo proste i sprowadzało się w poszczególnych akcjach do podobnego kodu:
  1. <?php
  2. $wrapper = new PropelWrapper($this->getAgaviContext());
  3. try {
  4. if ($mode == 'new') {
  5. $object = $wrapper->createAndBindObject('Invoice');
  6. } else {
  7. $object = $wrapper->readAndBindObject('invoice', 'nazwa_pola_z_id_obiektu');
  8. }
  9. // tu otwarcie transakcji 
  10. $object->save();
  11. // i zamknięcie
  12. return 'Success';
  13. } catch (WrapperException $e) {
  14. handleWrapException($e);
  15. } catch (PropelException $e) {
  16. handlePropelException($e);
  17. } catch (Exception $e) {
  18. handleException($e);
  19. }
  20.  
  21. ?>

Przy odrobinie wysiłku akcja mogła by sprowadzać się tylko do:
  1. <?php
  2. // tym kodem załatwiamy edycję
  3. class InvoiceEditAction extends InvoiceInnerAction {
  4.  
  5. }
  6.  
  7. // tym kodem dodawanie
  8. class InvoiceAddAction extends InvoiceInnerAction {
  9. }
  10.  
  11. // klasa bazowa dla operacji z fakturą
  12. class InvoiceInnerAction extends WrapperAction {
  13. // jedyna rzecz jakiej wymaga od nas wrapper
  14. protected function getClassName() {
  15. return 'Invoice'
  16. }
  17. }
  18.  
  19. // tym kodem listowanie
  20. class InvoiceListAction extends ListAction {
  21. protected function getClassName() {
  22. return 'Invoice'
  23. }
  24. }
  25. ?>



Napisanie takiego "czegoś" to na prawdę ciekawe zadanie a integracja z zewnętrznymi bibliotekami może dać na prawdę sporo możliwości. Np kod, który udało mi się stworzyć w końcu zaczęła używać osoba, która nie była programistą tworząc widoki od ręki bazując tylko na strukturze bazy danych. Jedyna rzecz jaką musiała potrafić to dobrze sklecić szablon Smarty. Programista wówczas pisał logikę i nie zawracał sobie głowy resztą.


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
Martio
post 26.02.2008, 00:54:43
Post #49





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

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


Używam Zend Frameworka. Chciałbym oddzielić warstwę logiki biznesowej od warstwy dostępu do danych. Dla warstwy logiki biznesowej najlepiej pasowałoby zastosować wzorzec "Domain Model". Jak wykorzystać "Zend_Db_Table" wraz z "Zend_Db_Table_Row" jako warstwy dostępu do danych? Mogę prosić o praktyczne zastosowanie?
Go to the top of the page
+Quote Post
regis87
post 26.02.2008, 20:05:52
Post #50





Grupa: Zarejestrowani
Postów: 36
Pomógł: 0
Dołączył: 9.11.2003

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


Testowałem różne dostępne rozwiązania ORM, najlepiej moim zdaniem wypada DoctrinePHP. Jest bardzo prosty w implementacji, wygodny, ma ogromne możliwości. Także jeżeli komuś zależy na takich "ułatwieniach" to zdecydowanie polecam. Ja jednak zostanę przy pisaniu zapytań i "czystym" PDO. Powód? Pod koniec moich testów odpaliłem sobie Apache Benchmark.

Na bazie testowej (tabele: artykuly, users, tagi, artykuly_x_tagi - jakie tu panują relacje chyba widac smile.gif ) porównałem wydajność dwóch aplikacji:
1) w moim frameworku (prosty mvc, sesje, pare bibliotek, widok obsluguje TemplateLite) prosta aplikacja pobierająca rekordy z bazy, zapytania w SQL poprzez PDO;
2) te same zapytania w Doctrine i wyniki wyprintowane, bez żadnej "obudowy" w postaci frameworka, także teoretycznie powinno być wydajniej

Wyniki - prawie czterokrotnie większa wydajność pierwszej opcji. Wniosek - ORM to piękna rzecz, ale w dużych projektach gdzie wydajność to priorytet, lepiej sobie darować.
Go to the top of the page
+Quote Post
Sedziwoj
post 27.02.2008, 10:37:16
Post #51





Grupa: Zarejestrowani
Postów: 793
Pomógł: 32
Dołączył: 23.11.2006
Skąd: Warszawa

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


@regis87

I moim zdanie się mylisz, jak jest duży projekt bez ORM to masakra.
A co do wydajności, to jak masz wiele do wielu to tak zawsze jest, ale pamiętaj że korzystając z ORM najbardziej zachłanne rzeczy można przepisać na niższy poziom, czyli wykorzystując tylko abstrakcję bazy danych.

Do tego tak często nie doceniane widoki (przez większość zwane perspektywami) się przy stosowaniu ORM bardzo przydają.

Bo nie można zaprzeczyć, że ORM jest bardziej obciążający niż prosty dostęp, ale tak samo programowanie obiektowe (w tym wspomniane MVC) też jest wolniejsze od proceduralnego, jednak jakoś nikt na to nie zwraca zbytniej uwagi, chyba że jest jakiś punkt gdzie wydajność siada, ale to się małe fragmenty kodu zmienia, nie całą aplikację.
"Nie używajmy ORM", to prawie jakby mówić "piszmy w asemblerze". Może trochę przesadzam, ale jak się nie przestawia korzyści, i gada głupoty że w dużych projektach to lepiej bez... to mnie to irytuje.
Oczywiście zawsze się znajdzie coś co musi być napisane w asemblerze, ale to są na prawdę specyficzne rzeczy, a nie typowe aplikacje.


--------------------
Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami.
Go to the top of the page
+Quote Post
Cysiaczek
post 27.02.2008, 10:52:09
Post #52





Grupa: Moderatorzy
Postów: 4 463
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




W 100% popieram. Za całą obiektową otoczką takiego Propela lecą zwykłe zapytania SQL, a jedynie konieczność utworzenie obiektów ze zwracanego wyniku lekko spowalnia. Lepiej zatem (jak mówi Sedziwoj) pisać z użyciem ORM, a potem jedynie odnaleźć bardzo czasochłonne operacje i je przepisać. Zauważ, że jak coś jest bardzo zasobożerne, to jest to zazwyczaj operacja na ogromnych ilościach danych na raz. Z autopsji powiem, bo dziś w nocy troszkę potestowałem, że operacje z wyszukiwaniem LIKE %xxx% na 250 000 rekordach to 3.49 s gołe zapytanie i 3.6 s Propel (wliczam utworzenie paczki z danymi).

Pozdrawiam.


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
splatch
post 27.02.2008, 12:09:19
Post #53





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

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


Może w kwestii dużych projektów. Panowie nie zapominajmy, że duże projekty zazwyczaj stoją na dedykowanych maszynach, gdzie nie martwimy się tym, że nasz dostawca odetnie vhosta z racji na generowane obciążenie. Z drugiej strony - jakie są różnice czasowe, bo procentowo jest to dużo, ale czy będzie to odczuwalne dla użytkownika?
Nie pracowałem może w największych projektach, ale ilość linii kodu szła w tysiące czy też dziesiątki tysięcy. Gdyby każdy miał klepać zapytania, bo "tak jest wydajniej" to stracili byśmy na tym zbyt wiele czasu. Podstawą w takich wypadkach jest ORM i dobrze skonstruowane DAO, tak by nie pojawiały się metody duplikujące swe działania (pytanie - które DAO co może odczytywać). Zaoszczędzasz czas upraszczając sobie pracę z pozyskanymi danymi - w dalszym ciągu masz obiekty, w których możesz zawrzeć jakieś w miarę proste operacje, a nie półśrodki w postaci tablic bądź map. Chodzi o to, że gdy ORM stworzy Ci obiekt powiedzmy faktury - tworzysz metodę isPaid a w niej masz jakiś warunek. Normalnie, pisząc strukturalnie - ten warunek przerzuciłbyś do kontrolera bądź, co gorsza, widoku. Gdy coś się zmienia w sposobie uznawania płatności i masz ORM modyfikujesz tylko jedną metodę. Nie szukasz wszystkich warunków, gdzie dany typ danych się przewija.

Popatrzcie proszę na ORM przez perspektywę tego, co może dać nam obiekt smile.gif.


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
regis87
post 27.02.2008, 17:22:42
Post #54





Grupa: Zarejestrowani
Postów: 36
Pomógł: 0
Dołączył: 9.11.2003

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


Może źle to ująłem. Mówiąc o dużych projektach nie mam na myśli bardzo rozbudowanych aplikacji z ogromną funkcjonalnością. Chodzi mi raczej o serwisy, które wystawione są na działanie bardzo dużej liczby użytkowników, a więc wywołań. Sam rozmiar bibliotek ORM daje do myślenia - po skompilowaniu DoctrinePHP do pojedyńczego pliku, zajmuje on prawie 700KB. Bez kompilacji jest jeszcze gorzej, bo wszystko rozbite jest na nie dziesiątki, ale setki plików klas. Z tego co wiem podobnie wygląda to w przypadku Propela.

Ale... jakiś czas temu trafiłem na bibliotekę realizującą wzorzec ORM, o nazwie Pork. Jest bardzo mała, szybka... trzeba to przetestować smile.gif

http://www.schizofreend.nl/Pork.dbObject
Go to the top of the page
+Quote Post
Cysiaczek
post 27.02.2008, 17:27:41
Post #55





Grupa: Moderatorzy
Postów: 4 463
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




W przypadku Propela masz kilka plików + te, które sam wygenerujesz.
Rozumiemy, o co chodzi z dużą ilością odwiedzin, ale w którym momencie upatrujesz koniec sensowności ORM? Ile odwiedzin dziennie?


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
regis87
post 27.02.2008, 17:55:22
Post #56





Grupa: Zarejestrowani
Postów: 36
Pomógł: 0
Dołączył: 9.11.2003

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


Nie potrafię tego oszacować. Ale kiedy wydajność staje się problemem, w ORM w pierwszej kolejności szukałbym oszczędności...
Go to the top of the page
+Quote Post
Cysiaczek
post 28.02.2008, 00:47:10
Post #57





Grupa: Moderatorzy
Postów: 4 463
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




Jeśli dysponujesz dedykowanym serwerem, to moim zdaniem problemy zaczną się gdzieś w okolicach kilkudziesięciu tysięcy odsłon dziennie. Bardzo mało serwisów osiąga takie liczby. Ja bym w tym wypadku zainwestował w jakiś cache dla modelu danych, czy nawet w cachowanie całych stron www. Dopiero gdyby to nie pomogło, szukałbym optymalizacji zapytań. Nie będę rzucał liczbami, ale np. forum.php.pl mimo, że jest popularnym, średniej klasy forum nie osiąga jeszcze pułapu, przy którym zdycha sprzęt ;p

Pozdrawiam


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
Martio
post 28.02.2008, 18:36:04
Post #58





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

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


Cytat(Martio @ 26.02.2008, 02:54:43 ) *
Używam Zend Frameworka. Chciałbym oddzielić warstwę logiki biznesowej od warstwy dostępu do danych. Dla warstwy logiki biznesowej najlepiej pasowałoby zastosować wzorzec "Domain Model". Jak wykorzystać "Zend_Db_Table" wraz z "Zend_Db_Table_Row" jako warstwy dostępu do danych? Mogę prosić o praktyczne zastosowanie?


W sumie jakby nie było, to połączenie Zend_Db_Table_Row z DomainModel to wzorzec wypisz wymaluj.... ActiveRecord smile.gif

Mam pytanie do osób, które korzystają z wzroca Active Record. Czy implementujecie w nim logikę biznesową?

Przykład:

  1. <?php
  2. class Produkt extends ActiveRecord {}
  3. class Zamowienie extends ActiveRecord {
  4. public function obliczWartoscZamowienia() {
  5.  $produkty = $this->pobierzZamowioneProdukty();
  6.  
  7.  $wartosc = 0
  8.  
  9.  foreach ($produkty as $produkt) {
  10. $wartosc += $produkt->pobierzCene() * $produkt->pobierzIlosc();
  11.  }
  12.  
  13.  return $wartosc;
  14. }
  15. }
  16. ?>
Go to the top of the page
+Quote Post
menic
post 28.02.2008, 18:40:32
Post #59





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

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


@up: TAK


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

Uchwycić moment...
Go to the top of the page
+Quote Post
regis87
post 2.03.2008, 22:49:39
Post #60





Grupa: Zarejestrowani
Postów: 36
Pomógł: 0
Dołączył: 9.11.2003

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


Skończyłem testy, pork.dbObject. Jest imponujący pod względem wydajności i małych rozmiarów, ale ma ten mankament, że aby obsługiwać relacje pola w tabelach muszą być nazywane według ustalonego schematu. Ten schemat tak naprawdę wymusza PRAWIDŁOWE nazewnictwo pól: pole primary nazywa się ID_obiekt, pola będące kluczami relacji mają nazwy odpowiadających kluczy primary itd... ale wiadomo jak to wygląda w praktyce, rzadko zdarzają się tak ładnie skonstruowane bazy smile.gif
Autor mówi, że to właśnie takie ograniczenie pozwala na tę oszczędność kodu. Ale w planach ma dodanie funkcjonalności tworzenia relacji "ręcznie".

Ten post edytował regis87 2.03.2008, 22:50:56
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: 17.11.2019 - 06:01