Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

279 Stron V   1 2 3 > » 

Crozin
Napisane: 6.03.2019, 14:33:57





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

A czym jest i jakie wartości może przyjąć ów $zmienna?
  Forum: Przedszkole · Podgląd postu: #1239211 · Odpowiedzi: 2 · Wyświetleń: 161

Crozin
Napisane: 3.01.2019, 15:37:02





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Nie ma jednoznacznej odpowiedzi na pytanie null VS wyjątek VS null object VS optional VS jeszcze coś innego. Jest to niemal zawsze zależne od konkretnej sytuacji i od przewidzianego zachowania. Podaj konkretny przypadek użycia - wtedy można zastanawiać się co wybrać.
2. @Pilsener akurat Twoja sugestia odnośnie czegoś takiego:
  1. if ($sth->hasItem($key)) {
  2. $value = $sth->getItem($key);
  3. }
W przypadku zasobów nie będących w bezpośredniej władzy programu (tj. wszystko wykorzystujące sieć, dyski czy ogólnie środowisko systemu) jest po prostu zła i nieprawidłowa - prowadzi do błędów, bo pomiędzy sprawdzeniem (has()), a wykorzystaniem (get()) stan systemu może się zmienić. Tutaj tylko wyjątki dają sensowny interfejs, bo trzeba spróbować pobrać zasób (get()) by w ogóle stwierdzić czy jest on dostępny (has()).
  Forum: Object-oriented programming · Podgląd postu: #1238385 · Odpowiedzi: 12 · Wyświetleń: 1 253

Crozin
Napisane: 4.10.2018, 10:17:03





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

memory_get_PEAK_usage() jak sama nazwa od dokumentacji nie wspominając wskazuje zwraca najwyższe chwilowe zużycie pamięci jaki skrypt/program miał, nie obecne.

1. GC ma prawo zadziałać dopiero z opóźnieniem.
2. Musisz wczytywać wszystkie dane do pamięci przed ich zapisem? Nie możesz tego zrobić strumieniowo?

  Forum: Przedszkole · Podgląd postu: #1237049 · Odpowiedzi: 1 · Wyświetleń: 211

Crozin
Napisane: 7.09.2018, 13:08:43





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Czyli na indeks główny (PRIMARY KEY) lepiej stosować unsigned, bo wartości ujemne i tak się nie wykorzysta.
Nie lepiej, bo obsługa wartości bez znaku jest w wielu platformach mocno utrudniona - z PHP na czele - a niczego Ci nie daje w tym kontekście. Nie mówiąc już o dużych problemach w mieszaniu arytmetyki typów z i bez znaków.
Cytat
Z drugiej strony... Z moich testów wynika, że i tak przy ponad 100-300 tys. wpisów do bazy aplikacja PHP + MySQL strasznie zwalnia...
To będzie wina złego projektu aplikacji czy bazy danych, nie samej platformy/technologi. Nie przy takich wartościach.
Cytat
Cytat
Ustalanie wartości default'owych też nie ma sensu, bo i tak na dzień dobry mamy w obiektach wartości NULL, które trzeba zmienić przed zapisem do bazy. Inaczej wywali błąd.

Ma sens. Jeśli na 99% rekordów jakieś pole ma wartość 0, to po prostu nie ustawiasz tej wartości przy zapisie. DLa tego 1% zmieniasz (przed lub po zapisie) na inną wartoiść
To że jakaś wartość jest dominująca nie powinno być samo w sobie przesłanką do korzystania z wartości domyślnych. Przy czym jest to raczej mało istotna kwestia.
Cytat
W zwykłej aplikacji PHP też tak mam, ale we framework'u Symfony świeżo utworzony obiekt przed zapisem ma same wartości NULL. Ustawienia default'owe w bazie MySQL nic nie dają i wywala mi błąd, że chcę zapisać NULL. Jedynym rozwiązaniem jest ustawić wartości default'owe w konstruktorze, aby nie ustawiać wszystkiego set'ami przed każdym osobnym zapisem...
1. Symfony nie ma tutaj nic do rzeczy - to specyfika języka.
2. Jeżeli nulle nie mają sensu dla Twojego modelu danych - bardzo częsta sytuacja i w sumie jeszcze częściej mocno pożądana - nie umożliwiaj w ogóle ich podania. Od tego są konstruktory by wymusić podanie odpowiednich danych. Jeżeli zaś danych jest za dużo na konstruktor masz do dyspozycji całą paletę sprawdzonych wzorców budowniczych pozwalających konstruować złożone obiekty.
3. Jeżeli jakieś wartości trzeba ustawić to... to je ustaw.
  Forum: Bazy danych · Podgląd postu: #1236579 · Odpowiedzi: 10 · Wyświetleń: 1 677

Crozin
Napisane: 6.09.2018, 08:48:52





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

@rad11 Ale po co tak kombinować?
  1. $request = new Request(...);
  2. $requestStack = new RequestStack();
  3. $requestStack->push($request);
Tak długo jak długo nie trzeba używać żadnych mocków powinno się od nich uciekać. Request / RequestStack to bardzo proste obiekty, które spokojnie można tworzyć sobie na potęgę.

@szypi1989 Tutaj testy dają Ci nawet coś więcej niż pewność, że kod działa. Fakt, że jest Ci je tak trudno napisać ładnie obrazuje to, że kod jest - wybacz za bezpośredniość - słabo napisany. Zadaniem Twojej klasy jest zbudowanie odpowiedniego zapytania SQL/DQL na podstawie jakichś kryteriów. No to w takim razie skup się na tym by robił to i tylko to, korzystając z prostych i specyficznych dla tego problemu (zadania) typów danych.
  1. class AbcSearchCriteria {
  2. private string $name;
  3. private string $value;
  4.  
  5. public __construct(string $name, string $value) { ... }
  6.  
  7. public getName() { return $this->name; }
  8. public getValue() { return $this->value; }
  9. }
  10.  
  11. class AbcSearchQueryBuilder {
  12. public __construct($em, ...)
  13.  
  14. public buildQuery(AbcSearchCriteria $criter) { ... }
  15. }
To że w produkcyjnym kodzie te kryteria będą gdzieś, jakoś budowane na podstawie danych z żądania HTTP nie ma znaczenia dla tej klasy - ona ma się skupić na swoim zadaniu czyli budowaniu odpowiedniego zapytania na podstawie odpowiednich kryteriów. Ten kod strasznie łatwo przetestujesz i co więcej może to być wartościowy test! A co z tą kwestią tworzenia obiektu reprezentującego kryteria? To jest inna część kodu - może być inicjowana gdzieś pewnie na poziomie jakiegoś kontrolera, która powinna być poddana osobnemu testowi - który weryfikuje jedynie czy obiekt kryteriów jest prawidłowo tworzony na podstawie obiektu żądania HTTP.
  Forum: Frameworki · Podgląd postu: #1236537 · Odpowiedzi: 10 · Wyświetleń: 1 428

Crozin
Napisane: 2.07.2018, 13:06:27





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Na dobrą sprawę jest to dosyć proste do zrealizowania.

1. Link powinien zawierać w sobie jakieś ID komentarza, np. http://my-website/resouce-x?findComment=123.
2. Na pow. stronie wykonujesz zapytanie ustalające pozycję danego wiersza w ów liście komentarzy. Zrobisz to korzystając z ROW_NUMBER (w różnych silnikach baz może to widnieć pod inną nazwą). Tutaj przykład: https://stackoverflow.com/questions/1079480...-sql-result-set
3. Mając pozycję jesteś wstanie przekierować na odpowiednią stronę w listingu komentarzy, np. http://my-webiste/resource-x?commentsPage=23
  Forum: Bazy danych · Podgląd postu: #1234995 · Odpowiedzi: 3 · Wyświetleń: 1 457

Crozin
Napisane: 28.06.2018, 14:13:06





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. 2 116 590 bajtów (2 MiB) czy 2 116 590 kilobajtów (2 GiB)? Wtedy ten limit może mieć znaczenie.
2. Co to za ciąg, co to za dane, że chcesz ich tyle (o ile to faktycznie 2 GiB) wczytywać na raz do pamięci?
3. Jesteś wstanie udostępnić nam SSCCE?
  Forum: PHP · Podgląd postu: #1234903 · Odpowiedzi: 4 · Wyświetleń: 285

Crozin
Napisane: 18.06.2018, 14:30:32





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

@Damonsson: No przecież to co podałeś to nic innego jak właśnie losowy, nic nie znaczący identyfikator.
  Forum: Hydepark · Podgląd postu: #1234630 · Odpowiedzi: 10 · Wyświetleń: 889

Crozin
Napisane: 18.06.2018, 13:31:25





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Funkcje hashujące mają tylko małe litery.
Funkcje hashujące nie mają żadnych liter bo do dane binarne. Możesz je sobie co najwyżej zapisać w formie tekstowej.

Równie dobrze może to być po prostu losowy ciąg 32 znaków a-zA-Z0-9, który kompletnie nic nie oznacza. I byłoby to bardzo prawdopodobne jeżeli jest to publiczny identyfikator jakiegoś zamówienia.
  Forum: Hydepark · Podgląd postu: #1234626 · Odpowiedzi: 10 · Wyświetleń: 889

Crozin
Napisane: 16.06.2018, 11:58:34





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Wydaje mi się, że za bardzo skupiasz się w tej chwili na Symfony/Doctrine/innych bibliotekach oraz na problemach których jeszcze nie masz tworząc z relatywnie prostego problemu rozdmuchanego potwora, do którego faktycznie trudno podejść. Wcześniej pisałeś o tym jak już oczami wyobraźni widzisz strukturę i kontrakty pomiędzy obiektami, teraz piszesz o nieistotnych z punktu widzenia tego problemu bzdetach. smile.gif Zignoruj na chwilę problem obsługi bazy danych czy ogólnie ich składowania. Olej problem wprowadzania danych czyli formularze. Wypnij cztery litery na tworzenie serwisów w kontenerze zależności zrób to manualnie na start.

W skrócie: utwórz sobie prosty, śmieciowy kontroler z jedną akcją jako punkt wejścia do kodu, wpisz do niego ręcznie jakiś stan początkowy dla danych, uruchom kod który ma te dane przetworzyć i na koniec nawet najprostszym Symfonowym dump() wyświetl rezultat by sprawdzić czy otrzymane dane są prawidłowe.
  1. class DummyController {
  2. public function runAction(): Response {
  3. // Dane początkowe
  4. $staminaCalculator = new JakasDodatkowaUsluga();
  5.  
  6. $intervalA = new AbcInterval(new DateInterval('PT5M'));
  7. $intervalB = new RestInterval(new DateInterval('PT1M'));
  8. $intervalC = ...;
  9.  
  10. $athlete = new Athlete(endurance = 5, stamina = 10);
  11.  
  12. $blocks = ....
  13. $vcsettings = ...
  14. $workout = new Workout($blocks, $vcsettings)
  15.  
  16. // uruchom istotny kod, który w końcu coś robi
  17. $result = $workout->calculateDuration($athlete, $staminaCalculator); // przykladowo coś takiego
  18.  
  19. // wyświetl sobie dane by zweryfikować czy calculateDuration() działa prawidłowo
  20. dump($result);
  21.  
  22. die('a olać co tam by się chciało dalej dziać - nie ma znaczenia teraz');
  23. }
  24. }

Utwórz sobie kilka takich akcji, które pozwolą Ci zweryfikować czy istotny kod Twojej aplikacji działa poprawnie. Jak ten problem będziesz miał rozwiązany będzie można przejść do tematu zapisu jakiś danych do bazy - ale wtedy zobaczysz, że nie będziesz już musiał sobie w ogóle zaprzątać głowy obliczeniami i kod znowu będzie prosty. Później rozwiążesz sobie problem wydobycia danych z bazy czy np. z formularzy - dwa kolejne problemy do osobnego rozpatrzenia. I tak dalej i tak dalej. W tych późniejszych zadaniach Symfony/Doctrine mocno ułatwią Ci pracę, bo te problemy adresują i potrafią rozwiązywać - ale to później. "best practices" mają zastosowanie dopiero w momencie korzystania z elementów Symfony/Doctrine - ale to zaś: później. Pamiętaj też, że nad nimi powinny stać "best practices" pisania kodu samego w sobie, a to już jest mocno niezależne od bibliotek, frameworków czy nawet języków.

PS. Jeśli zamienisz sobie śmieciowy kontroler na klasę testu jednostkowego, a dump() na serię assert() będziesz miał książkowy przykład TDD w stylu AAA. :-)
  Forum: Object-oriented programming · Podgląd postu: #1234574 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 15.06.2018, 07:52:49





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Jednego tylko kurde nie mogę rozkminić - jak to wszytko ująć w ramach Symfony, tj jak później taki obiekt zapisać do bazy, jak utworzyć na podstawie przetworzonego formularza etc. Wszystko jest dość mocno powiązane z Entity i jakby filozofia frameworka jest na tym oparta. Te klasy typu FixedTimeInterval powinny dziedziczyć z Entity, żeby przy okazji być samym Entity?
Nie musisz, ani nawet nie powinieneś tego ujmować w ramach framworka. Jeżeli z jakiegoś powodu FW by Cię do tego zmuszał byłby to słaby FW - Symfony na szczęście taki nie jest, chociaż nieraz po dokumentacjach mocno sugerują takie użycie. Ten fragment kodu raczej się nie powinien przejmować żadnymi encjami czy innymi formularzami, bo jest od nich niezależny. Jeżeli potrzebujesz formularza, utwórz dla niego dedykowaną klasę reprezentującą formularz - nie korzystaj z obiektów domenowych czy innych encji tutaj. Analogicznie z encjami. Klasy z różnych części aplikacji (część domenowa, część dostępu do źródła danych - encje, część związana z obsługą formularzy) nie powinny między sobą dziedziczyć.

Jeśli masz już jakiś fragment zrealizowany możesz go tutaj pokazać i później zacząć się zastanawiać nad następnymi problemami. smile.gif
  Forum: Object-oriented programming · Podgląd postu: #1234512 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 11.06.2018, 10:05:18





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Nie bój się tworzyć wielu dedykowanych klas do rozwiązywania wielu różnych problemów w aplikacji. Unikaj raczej tworzenia "obiektu pod wszystkie możliwie zadania", bo to się nie sprawdza.
2. Staraj się by raczej detal implementacji warstwy zapisu danych (tutaj: baza danych + doctrine) nie wyciekał do innych warstw aplikacji. Innymi słowy obiekty domenowe same w sobie raczej nie powinny - bo i po co - mieć wiedzy n/t Doctrine'a.
Cytat
W innej części aplikacji mam np. bardziej rozbudowany serwis służący do generowania komend głosowych - korzysta on z serwisu zewnętrznego do generowania komend głosowych, z serwisu dokonującego tłumaczeń itp. Czy teraz obiekt workout powinien także takie rzeczy robić jak generować pliki dźwiękowe?
Tutaj musiałbyś lepiej przybliżyć sytuację.
Cytat
Czytając trywialne przykłady omawiające różne wzorce projektowe, gdzie klasy są na 5 linijek, a przykłady mocno uproszczone wszystko wydaje się oczywiste - ale jak trafia na normalną aplikację, to to wszystko przestaje być już oczywiste.
Dużą sztuką jest doprowadzić do tego by skomplikowany problem przedstawić w ujęciu trywialnego kodu. To jest jedna z trudniejszych umiejętności do nabycia.

IMHO zacznij sobie te problemy rozwiązywać po kolei, szybko prototypując. Pomiń na chwilę warstwę zapisu danych do bazy, skup się na problemie. Jak to będzie zrobione będziesz mógł przejść dalej, tj. do zapisu.
  Forum: Object-oriented programming · Podgląd postu: #1234260 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 8.06.2018, 06:11:08





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Przede wszystkim problemem tej klasy jest to, że musiałeś użyć aż trójelementowej listy by opisać co ona w ogóle robi. A robi zdecydowanie za dużo i powinna zostać rozbita na wyspecjalizowane obiekty.
2. Taka trochę ogólna uwaga co do tworzenia całych grafów encji, np. w createNewWorkoutBlock.
  1. $block=new WorkoutBlock();
  2. $task=new WorkoutTask();
  3.  
  4. $interval=new WorkoutInterval();
  5.  
  6. $rest=new WorkoutInterval();
  7. $rest->setType(WorkoutInterval::TYPE_REST);
  8. $rest->setDuration(10);
  9.  
  10. $task->addInterval($interval); // wylicza m. in. pozycję oraz ustawia dwu/jednostronną referencję
  11. $task->addInterval($rest); // j/w
  12. $block->addTask($task); // j/w
  13. $workout->addBlock($block); // j/w
  14.  
  15. // raczej nie powinno znajdować się to już w tej metodzie, ale jak już to wystarczy
  16. $this->em->persist($block);
  17. $this->em->flush();
  18.  
  19. return $block;
Tyle wystarczy, logika wyliczania pozycji i innych tego typu rzeczy może spokojnie zostać zamknięta w encji nadrzędnej.
3. Trochę analogicznie jest z klonowaniem. Też przeniósłbym to do metod w ramach encji. Swoją drogą uważaj przy korzystaniu z clone w przypadku encji. Można z tego korzystać, ale niesie to za sobą kilka implikacji (patrz: dokumentacja). Zdecydowanie polecałbym Ci zrobić całość klonowania ręcznie. Zdecydowanie upraszcza i bardziej klarowne staje się wtedy to czy robimy płytką czy głęboką kopię.
4. Encje traktuj tylko jako coś co wykorzystywane jest niemal wyłącznie w komunikacji z bazą danych, nie jako fundament obliczeń dla całej apki (niestety takie podejście jest bardzo popularne w sieci/dokumentacji symfony).
5. Uwzględniając powyższy punkt oraz to co widać w kodzie, wydaje się, że tutaj encje są fajnie zaprojektowane, ale dalsze wyliczenia dla faktycznej logiki aplikacji nie powinny już być wykonywane na nich, ale na wyspecjalizowanych obiektach (nowych klas) z części nazwijmy to domenowej aplikacji. Jaka będzie różnica pomiędzy tymi dwoma zestawami obiektów? Przykładowo te z części domenowej w ogóle nie potrzebują żadnej wiedzy na temat jakiegoś użytkownika, który widzę, że się tam przewija. Nie potrzebują też żadnych właściwości z serii itemOrder - potrzebują, by kolekcje podrzędnych obiektów były po prostu uporządkowane (co PHP-owe tablice zapewniają).
5. getWorkoutDistance - te trzy zagnieżdżone foreache powinny być raczej zastąpione jednym, gdzie źródłem danych będzie jakiś iterator. Co lepsze taki iterator mógłby od razu w momencie swojego tworzenia mieć przekazane jakiego typu interwałów w ogóle (nie)chcemy z niego uzyskać (3 zagnieżdżone foreache z ifem zmieniają się w jednego foreacha). A co jest jeszcze lepsze? Ta metoda w ogóle może być spokojnie przeniesiona do nowej klasy WorkoutZCzęściDomenowej.
6. W angielskim nie ma słówka "brutto". :-P
7. Analogicznie jak z getWorkoutDistance wydaje się, że getEstimatedWorkoutDuration, getWorkoutDuration, getBlockDuration czy getTaskDuration można przenieść do wybranych klas z części domenowej.
8. Te wszystkie duration nie wyrażałbym w intach czy floatach, a w DateInterval. Zdecydowanie lepiej będzie nadawać się do reprezentowania takiej wartości - chociażby ze względu na obsługę jednostek, co wydaje się bezwzględnie konieczne tutaj.
9. Te wszystkie metody z vcsettingsami też wydają się do przeniesienia.
10. Unikaj rzucania wyjątków klasy Exception - użyj bardziej wyspecjalizowanej, a jeżeli takie nie ma (która pasowałaby do danej sytuacji) stwórz swoją.
11. Mam wrażenie, że do wyliczania wielu z tych interwałów/modyfikatorów/temp i innych świetnie mogłoby nadać się podejście bazujące na wzorcu wizytatora (ang. visitor pattern). Tylko z tym wstrzymałbym się na początku, bo kto wie czy nie jest to już właśnie to zbytnie rozdmuchanie o którym wcześniej pisaliśmy.

I tak chyba doszedłem do końca tej klasy, co do której wydaje się, że... może ona spokojnie być kompletnie zaorana! tongue.gif Wtedy też problem z pierwszego punktu sam się rozwiąże.
  Forum: Object-oriented programming · Podgląd postu: #1234072 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 6.06.2018, 06:09:46





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Szczerze mówiąc nie jestem dokładnie pewien czy w pełni poprawnie rozumiem problem (tak patrząc całościowo) - to na start. smile.gif Nie wiem też czy przykłady jakie podałeś wyczerpują różnorodność detali czy właściwie na tym kończą się ich wariacje. Fajnie jakbyś może pokazał nawet jakąś okrojoną wersję kodu źródłowego (szczególnie $workoutService'u) - nieraz mówi więcej niż jego opis.
2. Bardzo ważne jest to jak bardzo chcesz, czy właściwie jak bardzo potrzebujesz "rozdmuchać" obsługę tego problemu. Chodzi o to by jednak potencjalnie prostego problemu nie zacząć rozwiązywać w niepotrzebnie rozbudowany, skomplikowany i obszerny sposób (takie ang. overengineering).
3. Wstępnie wygląda to tak, że obiekty pod $interval, $vcsettings czy $workout to wyłącznie wory do przenoszenia złożonych danych (DTO), a obliczenia z nimi związane zamiast być blisko danych w postaci metod (jak to jest przewidziane w OOP) są wyniesione gdzieś zupełnie indziej w kodzie.
4. Na początek spróbuj może troszkę odwrócić relację pomiędzy obiektami. Zamiast $workoutService->getDuration($workout, $vcsettings) spróbuj do tego podejść jako $workout->computeDuration(questionmark.gif$vcsettings??, questionmark.gif$workoutService??). Być może te $vcsettings powinny być przekazane już w konstruktorze, a ten drugi argument w ogóle stanie się już niepotrzebny?
5. Ten fragment kodu (związany z samą logiką aplikacji) w miarę możliwości nie powinien mieć nawet świadomości Symfony, Doctrine'a (encji) czy innych frameworków. Dlaczego? Bo takie webowe FW nie chcą rozwiązywać konkretnych problemów, specyficznych dla Twojej aplikacji. Mają dać Ci szybką, solidną i wygodną "otoczkę" niezwiązaną bezpośrednio z celem działania samej apki (tutaj: wyliczania terningów), a związaną z całym tym "syfem" potrzebnym do tego by to gdzieś/jakoś/komuś uruchomić. tongue.gif Pozwól im skupić się na tym co faktycznie potrafią robić, samemu skupiając się mocno na swoim problemie - którego rozwiązanie już leży po Twojej stronie. smile.gif
  Forum: Object-oriented programming · Podgląd postu: #1233973 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 4.06.2018, 18:39:46





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Pytanie brzmi - jaki obiekt powinien obliczyć tą konkretną wartość, żeby było prawidłowo i zgodnie ze sztuką.
Nie wykorzystywać do tego w ogóle Doctrine'owskich encji, bo ich zadaniem nie jest reprezentowanie logiki aplikacji. Utwórz odpowiedni zestaw obiektów i kontraktów pomiędzy nimi do wykonania tych obliczeń/tego zadania. Ta część powinna być jak najmocniej przetestowana, bo tutaj testy są najbardziej wartościowe i faktycznie chronią przed błędami. Następnie utwórz drugi zestaw obiektów i kontraktów/relacji pomiędzy nimi do składowania tych danych w bazie (Doctrine'owskie encje). Na koniec przygotuj coś co pozwoli przenieść dane pomiędzy oboma strukturami. W każdej z tych trzech części skup się tylko na jednym zdaniu. Zazwyczaj tworzenie zewnętrznych usług do wykonywania obliczeń na niepowiązanych obiektach sprowadza się do programowania strukturalnego z wykorzystaniem obiektów/klas jako struktur transportujących dane - innymi słowy tracimy masę dobrodziejstw obiektówki.
  Forum: Object-oriented programming · Podgląd postu: #1233933 · Odpowiedzi: 13 · Wyświetleń: 2 275

Crozin
Napisane: 21.03.2018, 16:17:24





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Wepchasz to w JSON-a: będzie wolniejsze pod każdym względem: czasu zapisu, odczytu, modyfikacji, miejsca na dysku, czasu odczytu/zapisu przez PHP-a, wprowadzania zmian (będziesz musiał jak sam zaznaczyłeś pisać jakieś magiczne mappery/mergery) czyli ogólnie rzecz biorąc: dewelopmentu. Po co to wszystko? Jeżeli masz zasób, który składa się z relatywnie dużej liczby właściwości... no OK, z reguły jest to oznaka czegoś złego, ale tutaj nie wydaje się tu być przypadkiem. Tylko zlituj się sam nad sobą i stosuj pełne nazwy dla kolumn - to nie lata 80 by długość tego typu nazw miała dla czegoś znaczenie.
  Forum: Bazy danych · Podgląd postu: #1230949 · Odpowiedzi: 19 · Wyświetleń: 1 710

Crozin
Napisane: 21.03.2018, 11:30:53





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Doctrine'owska encja faktycznie będzie miała wtedy 30 właściwości i niech je sobie ma, skoro ona ma na dobrą sprawę odzwierciedlać to co jest w bazie danych. Jeżeli część z tych danych można jakoś sensownie zgrupować też to możesz zrobić przy pomocy @Embeeded. Przecież encję i tak wykorzystuje się tylko na poziomie/w warstwie aplikacji przy bezpośredniej komunikacji ze źródłem danych, także zbyt często z tym potworkiem do czynienia mieć nie będziesz. smile.gif

Innymi słowy - mając 30 różnych danych (a wszystko wskazuje na to, że masz) musisz prędzej czy później się z nimi w kodzie spotkać i zdecydowanie lepiej mieć każdą z nich jawnie i klarownie zdefiniowaną.
  Forum: Bazy danych · Podgląd postu: #1230929 · Odpowiedzi: 19 · Wyświetleń: 1 710

Crozin
Napisane: 21.03.2018, 08:59:07





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Tak jak pisałęm są to dane numeryczne int, decimal.
Jeżeli każda z tych ~30 wartości reprezentuje coś innego, coś unikalnego, coś co nie jest jakąś grupą/kolekcją/agregatem danych to każda z nich powinna być osobnym bytem - w przypadku bazy danych: kolumną.
Cytat
Nie będzie wyszukiwania po tych danych, filtrowania ani innych operacji.
Nie potrzebujesz wykonywać takich operacji teraz do osiągnięcia wymaganego efektu, ale nie zdziw się jak za 5 miesięcy, ktoś Cię poprosi o wycinek danych z marca, albo o ten raport za jakieś 5000 czy 6000 czegoś tam i najszybszym wykonaniem tego nowego zadania będzie napisanie prostej SQL-ki.
Cytat
Zawsze pobierane są wszystkie te dane bo generowany jest z nich PDF i dodatkowo widok tabelaryczny.
No i od tego mamy SELECT * .... ;-)

Cytat
Dla tego zastanawiałem się nad ew. optymalizacją [...]
Tu tkwi sendo problemu. smile.gif Masz w ogóle jakiś problem wydajnościowy? Co chciałbyś optymalizować? Szybkość dewelopmentu, przyszłe utrzymanie, szybkość pobierania danych, objętość danych na dyskach/w pamięci? Od razu podpowiem, że z sugerowanych "optymalizacji" wszystkie pogarszają wymienione przeze mnie aspekty.
Pamiętaj, że przedwczesna czy mikro optymalizacja to niemal zawsze złe rozwiązanie.
  Forum: Bazy danych · Podgląd postu: #1230913 · Odpowiedzi: 19 · Wyświetleń: 1 710

Crozin
Napisane: 21.03.2018, 08:02:33





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

> Ja wiem że pakowanie w szerz to nie jest najlepszy pomysł dla tego słcuam głosu ludu
Ale dlaczego? Jeżeli to są sensowne, różnorodne dane, co to jest w tym złego? Co to są dokładnie za dane? Trzymanie tego w formie jakieś zserializowanej tablicy, JSON-a itp. będzie najprawdopodobniej dużo mniej optymalne pod względem szybkości działania, objętości zajmowanego miejsca na dyskach/w pamięci, nie mówiąc już o jakimkolwiek wyszukiwaniu/filtrowaniu danych.
  Forum: Bazy danych · Podgląd postu: #1230906 · Odpowiedzi: 19 · Wyświetleń: 1 710

Crozin
Napisane: 9.03.2018, 13:14:34





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Nie każda warstwa abstrakcji będzie powodowała spowolnienie, jeżeli np. sama w sobie potrafi coś optymalizować, co normalnie by optymalizowane nie było - np. Second-Level Cache z Doctrine'a.
2. Ilość danych w bazie nie ma dla samego Doctrine'a specjalnego znaczenia.
3. Znaczenie będzie miała natomiast liczba wyciąganych przez dane zapytanie danych. Przetworzenie przykładowo 100 000 rekordów z bazy danych przy pomocy "czystego PHP-a" może być znacząco szybsze niż zrobienie tego z wykorzystaniem Doctrine'a ze względu na powolność PHP-a w tworzeniu obiektów jako takich.
4. Musisz sprawdzać jakie zapytania SQL finalnie generuje Doctrine. A że pracując z ORM-em często łatwo się zapomnieć w tym aspekcie stąd opinia n/t "powolnych ORM-ów".
  Forum: Bazy danych · Podgląd postu: #1230360 · Odpowiedzi: 3 · Wyświetleń: 1 076

Crozin
Napisane: 30.01.2018, 07:08:52





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Jedna mała acz bardzo, bardzo istotna uwaga. W MySQL kodowanie UTF8 to utf8mb4, nie utf8 - o tym ostatnim należałoby właściwie zapomnieć. smile.gif
  Forum: MySQL · Podgląd postu: #1228285 · Odpowiedzi: 9 · Wyświetleń: 1 257

Crozin
Napisane: 4.01.2018, 07:36:08





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

1. Jeżeli nie masz doświadczenia z szerokopojęta kryptografią nie próbuj robić niczego samemu - nie skończysz na tym za dobrze.
2. https://stackoverflow.com/questions/1820311...ers-have-the-sy
3. W praktyce jeżeli chcesz mieć pewność (czy właściwie większe prawdopodobieństwo), że nikt nie uzyska dostępu do Twojego oprgoramowania nie udostępniaj go. Udostępnij je jako całą usługę, tj. samodzielnie zajmuj się jej utrzymaniem dla poszczególnych klientów.
  Forum: PHP · Podgląd postu: #1227041 · Odpowiedzi: 2 · Wyświetleń: 306

Crozin
Napisane: 7.12.2017, 18:34:24





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

A możesz napisać co chciałbyś dzięki temu osiągnąć? Bo odnoszę wrażenie, że to nie jest najlepsze rozwiązanie problemu jaki masz.
  Forum: Frameworki · Podgląd postu: #1225938 · Odpowiedzi: 4 · Wyświetleń: 793

Crozin
Napisane: 13.11.2017, 13:25:22





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Cytat
Nie da się generalnie odpowiedzieć na pytanie: Jak poprawnie w klasie użyć (np) 5 różnych obiektów?
Na takie pytanie można odpowiedzieć jedynie mając kontekst konkretnego przypadku. smile.gif
Cytat
Bo rozumiem, że poprawnie byłoby wstrzykiwać instancje jako parametry konstruktora (Dependency Injection), ale tu też książka mówi, że nie ładnie mieć wiele argumentów.
I generalnie rzecz biorąc ta książka bardzo dobrze mówi. Co zatem w przypadku, gdy w kontruktorze potrzebowałbym 23 argumentów? Najprawdopodobniej mamy do czynienia ze źle zaprojektowanym obiektem, który próbuje zajmować się zbyt dużą liczbą rzeczy na raz.
Cytat
Jeśli jest to kontroler to tutaj spinasz generalnie wszystko więc ilość zależności może być spora [...]
Kontrolery to dokładnie takie same klasy jak wszystkie inne. Nie powinny spinać wszystkiego, bo co jest do wszystkiego to jest do niczego. ;-) Z jakiegoś powodu da się w sieci znaleźć "odczucia", że kontrolery to jakieś specjalne klasy - nie, nie są w żaden sposób wyjątkowe.
Cytat
W sensie klasa biznesowa raczej powinna po prostu coś zwracać bez większych kombinacji z innymi klasami, a w kontrolerze żongluję tymi klasami biznesowymi. Tak?
Wręcz dokładnie odwrotnie. :-) To własnie klasy/metody z części "logiki biznesowej" potrzebują wykonać całą ciężką pracę w programie, więc to w nich znajdziemy sporo zależności. Inną kwestią jest to, że nadal trzeba trzymać się zasady - im mniej zależności tym lepiej.

W skrócie: musiałbyś podać konkrety przypadek do omówienia (code review) nawet w jakimś pseudokodzie, bo tak to będziemy prowadzić akademicki wywdów. smile.gif
  Forum: Przedszkole · Podgląd postu: #1224515 · Odpowiedzi: 7 · Wyświetleń: 259

Crozin
Napisane: 13.11.2017, 10:06:43





Grupa: Zarejestrowani
Postów: 6 476
Dołączył: 6.08.2006
Skąd: Kraków

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

Przede wszystkim trzeba pamiętać, że wszystkie hasła jakie podałeś, są dosyć... ogólne. We wszystkim trzeba zachować umiar i zdrowy rozsądek. Pokaż kod, który chciałbyś zweryfikować pod kątem zgodności z dobrymi praktykami, będziemy mogli ocenić czy coś wymaga poprawy czy nie.
  Forum: Przedszkole · Podgląd postu: #1224492 · Odpowiedzi: 7 · Wyświetleń: 259

279 Stron V   1 2 3 > » 

New Posts  Nowe odpowiedzi
No New Posts  Brak nowych odpowiedzi
Hot topic  Popularny temat (Nowe)
No new  Popularny temat (Brak nowych)
Poll  Sonda (Nowe)
No new votes  Sonda (Brak nowych)
Closed  Zamknięty temat
Moved  Przeniesiony temat
 

RSS Wersja Lo-Fi Aktualny czas: 20.06.2019 - 04:46