Wpis z mikrobloga

@GeneralX:

1. Piszesz kod domenowy – ustalasz „inwarianty” – przydają się ValueObjects.
2. Piszesz UI, robisz jak najwięcej walidacji HTML5+JS => żeby użytkownik miał szybki feedback, a nie jakieś średniowieczne przeładowania strony.
3. To, czego nie pokryłeś w walidacji po stronie przeglądarki, uzupełniasz walidacją Symfonową.

---

ad.1

Przykład:

class Person
{
    public function setAge(int $age)
    {
        if ($age <= 0) {
            throw new DomainException(sprintf('Age must be greater than 0, %d given',
@GeneralX: A jeśli pytasz o format reguł walidacji: osobiście preferuję ustalać je bezpośrednio przy robieniu Form Typea – chyba, że mam jakieś ładne DTO dla formularza, to być może zdecydowałbym się na annotacje albo Yamle (w jednym projekcie używamy Yamli – tylko minus jest taki, że trzeba grepować, żeby dowiedzieć się czy są jakieś reguły zdefiniowane – więc chyba pokusiłbym się przy następnym do annotacji).
@MacDada: Mam jeszcze takie pytanko odnośnie Value Objects. Jakim atrybutem mam wywoływać swoje własne walidaje w FormType?

Zróbmy to z twoim przykładem Person

$builder
->add('age',TextType::class,array(
'label' => 'Wiek', //wiem że texttype ale specjalnie to zrobiłem
))


Znalazłem to https://kacper.gunia.me/validating-value-objects/ i się troszkę zgubiłem. Tutaj tworzy niby to samo, ale znowu daje waliduje przez adnotacje co jest praktycznie powtarzaniem tych samych reguł. W form type za to tak wywołuje że tworzy tylko
Tutaj tworzy niby to samo, ale znowu daje waliduje przez adnotacje co jest praktycznie powtarzaniem tych samych reguł.


@GeneralX: To są dwie oddzielne warstwy. Jedna to biznesowa („sanity check” w ValueObject), a druga to warstwa UI (formularze Symfonowe służą do komunikacji z użytkownikiem).

Każda warstwa ma trochę inne zadania.

Coś jest ważne dla biznesu, to umieszczasz tę informację w warstwie biznesowej. Np to, że użytkownik musi być pełnoletni. W ten sposób,
nie prościej byłoby dodać adnotacje w entity tak jak robią w dokumentacji?


@GeneralX: Zależy. Jak robisz CRUDa, małą appkę, to wywalone.

Jak robisz duży projekt, to chcesz się oddzielić od infrastruktury, UI, frameworka i innych warstw. Twój model ma być Twój. Tak, żebyś mógł zmienić fw, infrastruktę czy UI. I żeby było jasne co wymaga biznes, a co wynika z wymagań innych warstw.

Generalnie dobry kod ma warstwy, jak Szrek czy