Wybór Frameworka. |
Wybór Frameworka. |
27.09.2008, 14:48:58
Post
#81
|
|
Grupa: Zarejestrowani Postów: 1 415 Pomógł: 117 Dołączył: 7.09.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
|
|
|
27.09.2008, 17:09:16
Post
#82
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Ja zdaje się zrozumiałem co chciał kolega powiedzieć, ale emp chyba nie rozróżnia frameworka od gotowego oprogramowania. Co za różnica czy oprogramowanie jest tworzone na podstawie frameworka czy pisane od podstaw? W sensie "dla klienta" oczywiście? Przecież używanie frameworka nei polega na przerabianiu tego samego softu dla 20 różnych klientów... Framework ma "tylko" automatyzować powtarzalne zadania.
|
|
|
27.09.2008, 17:56:30
Post
#83
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) |
Dobra już nie ma co karmić trolla. Koleś widać, że nie ma zielonego pojęcia co jest framework i jakie jest jego zastosowanie.
Choć z drugiej strony podziwiam determinację ludzi, którzy strugają swój własny młotek jak mają zamiar wbić gwoździa. Żeby ta dyskusja wróciła do odpowiedniego, wyższego poziomu sugeruję pominąć wypowiedzi ~emp i nie odpisywać na nie. Część ludzi po prostu nie jest reformowalna. |
|
|
8.12.2008, 09:14:17
Post
#84
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
@athlabus:
Fakt, stworzyć aplikację na pewno można szybciej przy pomocy Symfony (generator modeli, generator admina etc.). Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza. Co tam jeszcze... konfiguracja w *.yml. No dobra, fajnie, ale często miałem problem typu "!@#$% jak to zapisać w YML?". M.in. z tych właśnie powodów odszedłem od Symfony - za dużo kombinowania jak dla mnie. Jeżeli dobrze Ci się kodowało w CI to zapewniam Cię, że w K będzie Ci się kodowało jeszcze przyjemniej. Wybór jednak należy do Ciebie, my możemy jedynie wyrazić nasze prywatne zdanie. |
|
|
8.12.2008, 11:45:33
Post
#85
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
@phpion
Hehe tu właśnie dochodzi kwestia gustów. Każdy z nas ma inne oczekiwania do frameworka. Ja zrezygnowałem z CI z powodu kiepskiej obiektowości (wiem, że Kohana pod tym względme jest dużo lepsza) oraz ogólnie dużej prostoty (dużo rzeczy trzeba było sobie samemu dorobić). W Symfony cenię to, że 95% standardowych rzeczy mam "out of the box" i "ready to use". Wiąże się to też z pewnymi ograniczeniami - np. wspomniane przez Ciebie wykorzystanie Propela jako ORM. Widoki co prawda Propel wspiera, ale fakt faktem, że abstrakcja wymusza zrezygnowania z opcji niestandardowych, jak np. dodatkowe typu pól w Postgresie. Można oczywiście zrezygnować z Propela i pisać wszystko samemu, ale wtedy traci się wiele udogodnień, które oferuje w Symfony. Symfony ma też ten "minus", że wymaga znajomości/douczenia się pewnych zagadnień typu Prototype, Propel, subframework do formularzy czy konstrukcja yml - wynika to z tego, że Symfony wykorzystuje wiele komponentów napisanych przez kogoś innego. Jest to z jednej strony plus (bardziej dojrzałe i przetestowane rozwiązania), ale z drugiej strony wymaga większego wkładu w naukę na początku aby móc wykorzystać 100% możliwości. Ogólnie jednak powiem Ci, że testowałem 3 frameworki i w każdym dopisywałem sobie pewne "skróty" i dodatki. Po przerzuceniu się na Symfony okazało się, że tam już wszystkie te rzeczy były i to w zasadzie miały podobne api do tego co ja napisałem. Można więc powiedzieć, że w Symfony jest tok myślenia jaki ja preferuję. Teraz gdy powoli przerzucam się na Symfony 1.2 widzę, że dodano tam jeszcze więcej tego typu umilaczy. Ty masz pewnie podobnie w Kohanej. |
|
|
8.12.2008, 18:05:04
Post
#86
|
|
Grupa: Zarejestrowani Postów: 122 Pomógł: 8 Dołączył: 20.10.2008 Ostrzeżenie: (0%) |
@athlabus: Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza. No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli. Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM. |
|
|
8.12.2008, 18:20:32
Post
#87
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli. No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela? Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM. No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem. |
|
|
8.12.2008, 18:34:37
Post
#88
|
|
Grupa: Zarejestrowani Postów: 122 Pomógł: 8 Dołączył: 20.10.2008 Ostrzeżenie: (0%) |
No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela? No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem. To jak to wygląda w Kohana? Możesz to pokrótce opisać, bo szczerze mówiąc nie znam tego, a jestem ciekaw. Chodzi mi o etap przygotowania schematu bazy danych oraz dostępu. I czy w Kohanie masz abstrakcję na obu tych etapach? |
|
|
8.12.2008, 19:18:32
Post
#89
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
Nie, w K tworzysz bazę danych "ręcznie" (co dla mnie jest dużą zaletą), natomiast cała komunikacja z bazą danych realizowana jest z użyciem abstrakcji.
|
|
|
8.12.2008, 19:27:25
Post
#90
|
|
Grupa: Zarejestrowani Postów: 122 Pomógł: 8 Dołączył: 20.10.2008 Ostrzeżenie: (0%) |
Nie, w K tworzysz bazę danych "ręcznie" (co dla mnie jest dużą zaletą), natomiast cała komunikacja z bazą danych realizowana jest z użyciem abstrakcji. To w takim razie chyba się nie zrozumieliśmy - pisząc abstrakcja miałem na myśli również abstrakcję definiowania schematu bazy oraz budowania sqli. To dają rozwiązania typu propel i doctrine. Tego Ci nie da np PDO (chyba, że się mylę). Oczywiście nie mówię, że jest to zaleta - bo sam się męczyłem, jak za pomocą doctrina napisać trochę bardziej skomplikowane zapytanie i skończyło się na bezpośrednim wykorzystaniu PDO. Niestety, nie ma rozwiązań idealnych. A czym Twoje rozwiązanie się różni od tego co napisałem wcześniej? Cytat Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.
|
|
|
8.12.2008, 19:39:03
Post
#91
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
To w takim razie chyba się nie zrozumieliśmy I chyba dalej się nie rozumiemy Kohana nie posiada generatora bazy danych na podstawie napisanego schematu (schema.yml). Cały schemat (tabele, kolumny, relacje itd.) tworzysz ręcznie. Natomiast jeśli chodzi o samą komunikację z bazą danych to K posiada warstwę abstrakcji bazy danych (MsSQL, MySQL, MySQLi, PostgreSQL). Dodatkowo (i chyba o to Ci chodzi) posiada tzw. query builder czyli narzędzie służące do dynamicznego tworzenia zapytań: http://docs.kohanaphp.com/libraries/database/builder Można również korzystać z bezpośrednich zapytań do bazy. |
|
|
8.12.2008, 20:23:55
Post
#92
|
|
Grupa: Zarejestrowani Postów: 122 Pomógł: 8 Dołączył: 20.10.2008 Ostrzeżenie: (0%) |
I chyba dalej się nie rozumiemy Kohana nie posiada generatora bazy danych na podstawie napisanego schematu (schema.yml). Cały schemat (tabele, kolumny, relacje itd.) tworzysz ręcznie. Ok, to rozumiem - piszesz ręcznie sqla z create table itp. Ale i tak tracisz przy tym abstrakcję, bo piszesz pod konkretną bazę danych. Za to możesz skorzystać z rzeczy typowych np tylko dla postgresa. Natomiast jeśli chodzi o samą komunikację z bazą danych to K posiada warstwę abstrakcji bazy danych (MsSQL, MySQL, MySQLi, PostgreSQL). Czyli coś podobnego, co daje PDO. Czy ta abstrakcja w K korzysta z PDO czy to jest coś zupełnie innego? Dodatkowo (i chyba o to Ci chodzi) posiada tzw. query builder czyli narzędzie służące do dynamicznego tworzenia zapytań: http://docs.kohanaphp.com/libraries/database/builder Ok, czyli to jest jedyny element, którego nie masz w symfony jeśli decydujesz się na rezygnację z któregoś z ORM. Jednym słowem - punkty 1 i 2 można osiągnąć w symfony, jeżeli zdecydowałbyś się nie używać propela (w sf 1.2 jest to nawet jako plugin, który można wyłączyć). Jedyne czego nie ma, to ten query builder. Być może w kolejnych wersjach symfony pojawi się takie "lekkie" rozwiązanie wspomagające dostęp do bazy danych, lub ktoś wypuści jakiś plugin. A propo kolejnych wersji - nie wiem, na ile ta strona zawiera prawdziwe oraz aktualne informacje http://trac.symfony-project.org/wiki/Symfony2Discussion ale jest tam coś takiego: Orm:
|
|
|
9.12.2008, 11:32:14
Post
#93
|
|
Grupa: Zarejestrowani Postów: 627 Pomógł: 33 Dołączył: 1.05.2005 Skąd: Katowice Ostrzeżenie: (0%) |
Czy ta abstrakcja w K korzysta z PDO czy to jest coś zupełnie innego? nie korzysta. typowy ActiveRecord. ORM jako osobna biblioteka. -------------------- |
|
|
9.12.2008, 11:37:52
Post
#94
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) |
Ostatnio oglądałem sobie to całe Kochana Chyba nawet skuszę się na kilka "stronek" w tym, ale jak znajdę chwilkę czasu na przeczytanie dokumentacji, która pozostawia wiele do życzenia (wróć, jest po prostu dardzo słaba) i jak podłączę tam Propela 1.3.
|
|
|
9.12.2008, 15:23:57
Post
#95
|
|
Grupa: Zarejestrowani Postów: 627 Pomógł: 33 Dołączył: 1.05.2005 Skąd: Katowice Ostrzeżenie: (0%) |
jezu. jak @Mike zrobi cos w Kohanie to znaczy że świat stanął na głowie
ps. dokumentacja nie nadąża za zmianami ale taka fatalna to nie jest. chyba -------------------- |
|
|
9.12.2008, 19:51:10
Post
#96
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
dokumentacja nie nadąża za zmianami ale taka fatalna to nie jest. chyba Też jestem zdania, że nie jest najgorsza. Powiedziałbym wręcz inaczej: jest wystarczająca. Jeżeli mam jakieś wątpliwości to sobie przeglądam źródła klas i w bardzo krótkim czasie jestem w stanie połapać się co i jak działa (w przeciwieństwie do Symfony, a o Zend Framework już nie wspomnę hehehe). // Edit: Swoją drogą: dyskusja chyba zeszła nieco z tematu więc może lepiej byłoby przenieść niektóre posty do Wybór Frameworka? Ten post edytował phpion 9.12.2008, 20:06:14 |
|
|
9.12.2008, 20:47:51
Post
#97
|
|
Admin Techniczny Grupa: Administratorzy Postów: 2 071 Pomógł: 93 Dołączył: 5.07.2005 Skąd: Olsztyn |
j.w. cześć postów została wydzielona z Temat: [Symfony]Symfony_a_duze_projekty
|
|
|
9.12.2008, 21:14:49
Post
#98
|
|
Grupa: Zarejestrowani Postów: 627 Pomógł: 33 Dołączył: 1.05.2005 Skąd: Katowice Ostrzeżenie: (0%) |
można sobie w pare sekund wygenerować PHPDOCa ze źródeł Kohany, to też jest przydatne.
-------------------- |
|
|
16.12.2008, 21:41:58
Post
#99
|
|
Grupa: Zarejestrowani Postów: 96 Pomógł: 3 Dołączył: 15.04.2003 Skąd: Kraków Ostrzeżenie: (0%) |
Wracając do tematu wyboru frameworka: ja mam dylemat nieco inny, zainstalowałem sobie ostatnio Symfony, które miało być frameworkiem pod mój nowy projekt i ... no nie powiem jego możliwości robią wrażenie, ale projekt nad którym pracuje będzie softem "pudełkowym", (czyli pobierasz i instalujesz na hostingu z PHP i MySQL), tymczasem z tego co do tej pory zobaczyłem - delikatnie mówiąc - Symfony średnio się do tego celu nadaje.
Po pierwsze przeglądając źródło w wygenerowanym pliku ProjectConfiguration.class.php mam linie:
czyli bezwzględny adres do pliku na moim localhost, nie wiem czy takich require'ów lub include'ów jest więcej, bo narazie mało co zrobiłem, ale utwierdza mnie to w moim przekonaniu Po drugie w trac'u http://trac.symfony-project.org/wiki/SharedHostingNotSecure są specjalne patche i instrukcje jak instalować aplikacje na "shared hosting", to też mi dało do myślenia. Na koniec, przeglądając strony zrobione przy użyciu Symfony (http://trac.symfony-project.org/wiki/ApplicationsDevelopedWithSymfony) zauważyłem że zdecydowana większość to serwisy (prawdopodobnie) na serwerach dedykowanych. Na koniec dodam, że nie chodzi mi o to że Symfony jest złe a framework XXX jest lepszy, ale raczej o to, że Symfony nie zostało stworzone z myślą o aplikacjach które będą instalowane w setkach kopii (mam nadzieje ) na różnych hostingach, a na jednym serwerze dedykowanym i w przypadku takich aplikacji Symfony sprawdza się dobrze/świetnie/najlepiej (niepotrzebne skreślić)? -------------------- Linux is like wigwam, no windows, no gates and an apache inside.
Mój blog łebmasterski (po angielsku) Web Development Blog. |
|
|
16.12.2008, 21:55:21
Post
#100
|
|
Admin Techniczny Grupa: Administratorzy Postów: 2 071 Pomógł: 93 Dołączył: 5.07.2005 Skąd: Olsztyn |
takie require jest 1 w konfiguracji, jak zrobisz freeze to biblioteki sf zostana przekopiowane do odpowiednich katalogów i nie ma sie co tym martwić
a co do kopii to owszem sf jest bardziej pomyślane pod serwisy pojedyncze na dedykowanych maszynach, aczkolwiek działają równie dobrze na dzielonych |
|
|
Wersja Lo-Fi | Aktualny czas: 24.09.2024 - 05:47 |