[kot1401]

Mam w Laravelu dwa modele: User i Car

Car może być stworzony (kupiony) tylko jeśli user ma wystrarczającą ilość gotówki, czyli:

if($user->money - $car->price >=  0) {

   //user ma wystarczającą ilość gotówki

}else{

   //brak gotówki na ten samochod

}

Teraz pytanie: powyższa reguła powinna być umieszczona w validate modelu Car, czy w kontrolerze CarsController@store?

#laravel #php

[KubusiowyKubus]

@kot1401: dokladnie to OrderService :P

[kot1401]

@KubusiowyKubus: możesz opisać co to jest? Google nic nie znajduje :/

[normanos]

@kot1401: na pewno nie w kontrolerze bo co on ma do tego?

[MacDada]

@kot1401: Kontroler – odpowiada za komunikację między protokołem HTTP, a modelem aplikacji – tutaj bierzesz sobie GETy/POSTy/sesje/ciastka/itp i przekazujesz je dalej. Nic wiecej.

Entity\Car

– tutaj masz reprezentację samochodu. Przechowuje ona stan i raczej jest powiązana z bazą danych – nie ładowałbym logiki biznesowej (chyba, że robisz #ddd, ale wątpię, więc nie będę Ci mieszać).

Warstwa usług – tutaj ładujesz logikę biznesową. Czyli robisz sobie klasy dedykowane pod zadanie i

[KubusiowyKubus]

Zamiast ładować wszystko do controllera i myśleć gdzie wpakować funkcję "kup" rozdziel sobie to na warstwy. Uwórz OrderService - czyli serwis odpowiedzialny za kupno samochodu który w parametrach np przyjmuje encję user i encję car (Pamietaj! Model to nie tabela w bazie danych - mimo że niektórzy piszą że to model. Modelem jest wszystko co operuje na warstwie biznesowej - czyli modelem jest OrderService które komunikuje się z encjami User i Order).

[T.....n]

@kot1401: wiem że nie o to chodzi ale troche przekombinowany ten warunek, ja bym to zrobił tak

if($user->money >= $car->price)

[Atomic_Cookie]

@kot1401: To i ja dorzucę swoje 2 grosze. Wszystkie kluczowe funkcjonalności wrzucaj do serwisu. Głównym powodem jest to, że serwis można banalnie przetestować i mieć pewność, że w kontrolerze wszystko działa.

[kot1401]

@KubusiowyKubus: @Atomic_Cookie: @MacDada: moglibyście podać jakiś przykład kodu, jak wygląda taki serwis, encja i repozytorium?

Znalazłem tylko coś takiego: http://forumsarchive.laravel.io/viewtopic.php?id=16046 , ale nie ma tam żadnych skomplikowanych metod, tylko wyświetlanie obiektu :/

[Atomic_Cookie]

@kot1401: Ogólnie jak masz takie problemy to proponuję poczytać o SOLID. Najlepiej na przykładzie symfony2 (dobry kod oop). Encja wedle definicji to odwzorowanie części bazy, która jest unikalny. http://symfony.com/doc/current/cookbook/security/entity_provider.html Pierwszy kod php to encja - obiekt może mieć różne pola, ale encja ma pole które ją identyfikuje - w przypadku klasy user jest to id. Repozytorium to po prostu klasa z której pobierasz dane - http://culttt.com/2013/07/08/creating-flexible-controllers-in-laravel-4-using-repositories/ . Serwis to po prostu

[Atomic_Cookie]

@kot1401: Serwisy powinny być małe, zgrabne, wykonywać jedną operację i być testowalne (S w SOLID).

[kot1401]

@Atomic_Cookie: Czyli dla tego kodu: http://pastebin.com/70Kzwzj2 , muszę stworzyć trzy repozytoria: AirplaneRepository, AirplaneModelRepository, AirlineRepository plus serwis AirplaneService z metodą buy_airplane, która jako argumenty przyjmuje 3 encje z tych 3 repozytoriów?

i jak rozumiem, w tym serwisie sprawdzam, czy linia ma wystrczające środki i czy nie wybrano zbyt dużej ilosci foteli?

[KubusiowyKubus]

@kot1401: AirPlaneModel to encja reprezentująca Samolot. AirlineRepository służy do pobierania samolotów (list(), findById(), findByModel()), natomiast AirplaneService posiada (buy [nie dopisuj airplane bo się powtarzasz KISS się nasówa] - buy w parametrach ma id samolotu (lub nazwe, model itp itd) i user (user który chce kupić) i to wystarcza).

[kot1401]

@KubusiowyKubus: i serwis na podstawie tych parametrów (id samolotu, id usera), pobiera resztę danych z repozytorium?

Potem sprawdza czy samolot może być kupiony i zwraca wynik w postaci tablicy np.

array('result' => 'failed', 'errors' => array('Wybrałeś zbyt dużo foteli. Brak miejsca w kadłubie.')) 

?

[KubusiowyKubus]

@kot1401: https://gist.github.com/xfermi/a5f5fd5914ccf4cc11d1

[KubusiowyKubus]

@kot1401: Słuchaj encja to jeden samolot -> Repozytorium służy do pobierania samolotów na podstawie parametrów, w serwisie przeprowadzaj wszelakie operacje biznesowe (jak w linku wyżej)

[Atomic_Cookie]

@kot1401: @KubusiowyKubus:

Ja bym to rozwiązał inaczej, stosując zasady solid:

Tworzysz interfejs 'PurchasableInterface' który zawiera metodę getPrice()

Tworzysz serwis 'PurchaseService' który zawiera metodę 'purchase' która przyjmuje implementację interfejsu PurchasableInterface oraz użytkownika i w oparciu o to budujesz kontroler do kupowania. Dalej masz encję Airplane który implementuje interfejs PurchasableInterface, a oprócz tego Repozytorium. W ten sposób masz reużywalny kod.

[KubusiowyKubus]

@Atomic_Cookie: czyli Generalnie Encja -> Dao -> Repository -> Service. lub encja -> (DAO+Repository) -> serwis ale kto co lubi