Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ Frameworki _ [Symfony] Symfony 4.1 vs Framework3

Napisany przez: eerie 1.08.2018, 10:24:04

Witam

Napisałem prostą aplikację we framework'u Symfony 4.1. Chciałbym poddać ją Waszej ocenie. Czy może być tak napisana i co ewentualnie powinienem poprawić. Link do repozytorium jest tutaj:

https://github.com/webeeq/sieciq.eeq

I biblioteka do obsługi REST API:

https://github.com/webeeq/sieciq

Potem napisałem własny szkielet aplikacji w PHP 7.2. Wzorowałem go na framework'u Symfony. Starałem się, aby był możliwie najprościej napisany, by działał możliwie najszybciej. Link do SVN:

https://github.com/webeeq/framework3.eeq

Zastanawia mnie jedno. Symfony strasznie długo się prekompiluje (5-20 s). Potem działa dość szybko, ale moja aplikacja jest wiele razy wydajniejsza. Czy nie dyskredytuje to Symfony do używania przy projektach dla dużej rzeszy użytkowników? Czy nie lepiej jest wtedy napisać coś po swojemu?

Pozdrawiam
Robert

Napisany przez: kallosz 1.08.2018, 12:11:24

tak na szybko
* za dużo logiki w kontrolerach. Tam powinno znajdować się jak najmniej.
* komunikaty wiadomości email do wysłania w kontrolerach. Przenieś to do szablonu i tam ładnie formatuj przed wysłaniem.
* źle zaprojektowane encje

Cytat

Czy nie dyskredytuje to Symfony do używania przy projektach dla dużej rzeszy użytkowników?

IMO nie, dzięki temu że dużo rzeczy leci do cache nie ma potrzeby podobnego ich generowania.

Napisany przez: eerie 2.08.2018, 08:45:57

Cytat(kallosz @ 1.08.2018, 13:11:24 )

* za dużo logiki w kontrolerach. Tam powinno znajdować się jak najmniej.

Logiki jest tyle, ile było niezbędne, aby wiadomości wyświetlały się nad formularzami. Da się obsłużyć błędy w klasach formularzy i potem tylko wyświetlić nad danym polem formularza lub całym formularzem. Jak wszystko jest ok i nie ma błędów, to wyświetlić stosowną podstronę z informacją. Tak byłoby prościej. Tylko w pierwowzorze strony miałem taki zamysł, aby wyświetlać komunikaty tylko nad formularzem. Że coś jest ok czy też źle i podświetlać odpowiednim kolorem. Dlatego akurat w tej aplikacji sprawdzam podstawowe błędy w klasie formularza i potem je zwracam w kontrolerze do zmiennej z komunikatami. Potem dodaję kolejne, jak wybrana została jakaś akcja i np. udało się coś zapisać do bazy lub nie. Gdy udało się wysłać email lub nie. Potem obudowuję to w html i wyświetlam nad formularzem na stronie.

Czyli jak postępować w przyszłości? Tak skonstruować klasy formularzy, aby obsłużyć w nich wszystkie informacje o błędach, gdy spełnione są odpowiednie warunki? Jak nie ma błędów, to tylko wykonać zapis do bazy danych i przekierować na stosowną podstronę z komunikatem?

Cytat(kallosz @ 1.08.2018, 13:11:24 )

* komunikaty wiadomości email do wysłania w kontrolerach. Przenieś to do szablonu i tam ładnie formatuj przed wysłaniem.

Czyli w zależności od akcji tylko wysłać email'em stosowną podstronę html z komunikatem? Teraz jest tak, że wszystkie komunikaty obsługuje jeden szablon. Przekazywane są do niego tylko dane o nadawcy, odbiorcy, temat, wiadomość... Faktycznie. Można to zrobić prościej.

Cytat(kallosz @ 1.08.2018, 13:11:24 )

* źle zaprojektowane encje

Tu nie rozumiem... Generuje się z nich baza MySQL, jak chciałem. Tabele są odpowiednio powiązane. Gety i sety wygenerowały się automatycznie. Na to nie mam wpływu.

OK. Zrobię nową wersję strony z odchudzonymi kontrolerami i pokarzę do oceny.

Napisany przez: kallosz 2.08.2018, 18:44:05

Cytat

Tu nie rozumiem... Generuje się z nich baza MySQL, jak chciałem.

No i to jest błąd. Myślisz podejściem Database first. Nawet doctrine zaleca Model first. https://www.youtube.com/watch?v=rzGeNYC3oz0

Napisany przez: sabat24 3.08.2018, 10:00:38

Cytat

No i to jest błąd.

Uważasz to za błąd w ogóle, czy w tym konkretnym przypadku?

Napisany przez: kallosz 3.08.2018, 12:18:19

Błąd niezależnie od przypadku. Myślenie o tym że encja model ma nam odzwierciedlać bazę jest złym podejściem. Model powinien odzwierciedlać nasze cele biznesowe a nie służyć do generowania bazy.

Napisany przez: sabat24 3.08.2018, 17:28:49

Chodzi mi raczej o to, że myślenie podejściem Data First nie jest uznawane za błąd sam w sobie, a Model First nie zawsze musi być stosowane w pierwszej kolejności. Wszystko zależy czego potrzeba i co się chce osiągnąć.
Zgadzam się, że przy modelu nie masz odwzorować schematu bazy, jaki masz założony, bo nie masz mieć takiego założenia po prostu. Natomiast jeśli idziesz od strony architektury bazy danych, bo masz ku temu powód, to nic w tym złego.

Napisany przez: eerie 4.08.2018, 13:02:54

Ja zastosowałem podejście "Code First". Jest najbardziej lubiane przez programistów. Najpierw stworzyłem klasy encji w php na podstawie modelu, jaki rozrysowałem wcześniej na kartce. Pamiętałem o tym, aby zastosować „czwartą postać normalną”. Potem na podstawie kodu php wygenerowałem automatycznie bazę danych. Następnie wygenerowałem get'y i set'y.

Podejście "DB First" jest mniej wskazane. Stosuje się je, gdy zaczyna się pisanie aplikacji od gotowej bazy danych.

"Model First" jest prosty i wskazany dla początkujących programistów. Można na nim oprzeć raczej niewielką aplikację, gdy dysponujemy mało doświadczonym zespołem.

Napisany przez: memory 5.08.2018, 16:52:26

poczytaj o:
- dependency injection
- o autoryzacji w symfony i ogólnie. CookieLogin brak soli, login i hasło plaintextem, tak samo przy aktualizacji danych.
- nazewnictwo IsUserUser
- warto poczytać o szablonie twig

grube controllery

Napisany przez: eerie 7.08.2018, 17:45:56

Poprawiłem obsługę błędów formularzy, żeby było, jak pokazują w dokumentacji. Będę wdzięczny za wytknięcie wszelkich niedociągnięć. Tylko tak mogę podnieść kwalifikację. Najnowsza wersja aplikacji w Symfony 4.1.1 poniżej:

https://github.com/webeeq/sieciq2.eeq

Pozdrawiam
Robert