Aktywne Wpisy
Toshikate +15
#emigracja #holandia #praca #pracbaza #jedzenie #jedzzwykopem #gotujzwykopem
Od miesiąca jestem w Holandii i kurde to co tu można znaleźć w sklepach to naprawdę jest jakaś #!$%@? albo ja coś źle robię lub nie przywykłem XD Mięso mielone jak się kupi to mdłe jakieś wychodzi, chleb miękki tak że można go w rękach uformować w kulkę, wędliny to w
Od miesiąca jestem w Holandii i kurde to co tu można znaleźć w sklepach to naprawdę jest jakaś #!$%@? albo ja coś źle robię lub nie przywykłem XD Mięso mielone jak się kupi to mdłe jakieś wychodzi, chleb miękki tak że można go w rękach uformować w kulkę, wędliny to w
adrianoX +22
Nie odczuwam strachu przed samą śmiercią, lecz bardziej przed konceptem kontynuacji istnienia. Trudno mi wyobrazić sobie absolutną pustkę, która może nastąpić po śmierci. Być może ten stan nieistnienia trwa jedynie ułamki sekund, zanim zostanie się przywróconym do nowego życia. Rozwój życia na Ziemi zajął miliardy lat, a może nawet nieskończoną ilość czasu, co w moim odczuciu jest niezwykle złożone i ciężko mi sobie z tym poradzić
#kosmos #wszechswiat
#kosmos #wszechswiat
https://sarvendev.com/2022/10/an-absolutely-clean-domain-or-just-common-sense/
#programowanie #php #ddd
Ja nie wiem czemu ta branżą przyciąga tylu filozofów
Using ORM, but not use the full potential
to za bardzo nie widzę sensu. ORM to tylko szczegół implementacyjny i nie chcę się go uczyć tak, żeby robić fikołki. Naturalnym podejściem jest zawołanie jakiegoś SQLa i zmapowanie go na jakiś obiekt pośredni. Takie coś łatwo się debuguje i rozwija. Przy takim podejściu nie muszę się uczyć żadnego frameworka (również reszta devów, więc spada poziom złożoności), bo podejście "wołam@sarveniusz: to są dwa oddzielne argumenty
jak ktoś unika ORMa bo robi DDD i mu ORM przeszkadza ->
@Saly: w tym miejscu chodziło o wrzucanie do projektu skomplikowanego ORMa, a korzystaniu z niego na zasadzie tylko anemicznych modeli i mapowania do bazy, gdzie zamiast tego skomplikowanego narzędzia wtedy już lepiej to mapować właśnie samemu i pchać do bazy za pomocą prostego SQLa, będzie to lepsze
Separowanie się od frameworka nie jest darmowe, zwiększa stopień skomplikowania i ilość potrzebnego kodu. IMO temat sprowadza się do oceny ryzyka, jeżeli dodatkowy koszt zmiany frameworka wynikający z braku tej separacji przemnożony przez prawdopodobieństwo zmiany przewyższa narzut przy developmencie, to jak najbardziej jest sens. W przeciwnym wypadku robi się z tego trochę sztuka dla sztuki i kult cargo.
W sumie to z ORM rezygnuję jedynie w wybranych zapytaniach, ze względu na wydajność albo brak wsparcia dla window functions i innych "mniej standardowych" części SQL. Jak się kiedyś okaże że nie miałem racji to tak czy inaczej będę miał do przepisania repozytoria i atrybuty odpowiadające za mapowanie entitiesów. Wielkiej różnicy mi to nie robi, czy będą w tym samym czy w osobnym folderze.
@croppz: dużo zależy od community języka. W go większość używa standardowego
database/sql
(lub modyfikacji), który jedyne coWarto tylko pamiętać o automatyzacji i jakiejś weryfikacji reguł architektonicznych za pomocą phparch czy
Regułę mamy prostą, stopień izolacji jest odwrotnie proporcjonalny do stabilności dependenciesa. Symfony, doctrine i postgresa uznaliśmy za stabilne. ¯\_(ツ)_/¯
Raczej po prostu input DTO -> jeden lub parę powiązanych entity -> baza, w drugą stronę analogicznie tylko najczęściej DTOsy inne. A logika sobie radośnie traktuje encje jako bazodanowe DTOsy i ma w sumie w dupie czy pracuje z dtosem, czy z encją.
No i entity manager ze wszystkimi swoimi persistami, removami i flushami wypchnięty zawsze na top level, znaczy controller/command/handler.