2010-09-19 13 views
11

Prawdopodobnie słyszałeś o rozróżnieniu między grubym modelem/cienkim kontrolerem a rozrzedzeniem cienkiego modelu/tłumika. Ostatnio usłyszałem, że możesz mieć coś pomiędzy tym, gdzie część logiki z modelu przechodzi w warstwę usługi. Jak powszechne jest to? i czy znasz (lub potrafisz wymyślić) jakiekolwiek prawdziwe przykłady, które je ilustrują?Czy warstwa usługi MVC + jest wspólna w zend lub PHP?

+1

HMVC? Hierarchiczny kontroler widoku modelu? – WalterJ89

+0

@ WalterJ89 Aha, dzięki za słowo. Czy wiesz, kto wymyślił to przy okazji? – jblue

+0

Nie jestem pewien, kto to wymyślił. Po prostu pamiętam to z dokumentacji KohanaPHP. http://kohanaframework.org/ Jestem zaznajomiony z MVC, ale część H wciąż jest na mojej liście tolearn. – WalterJ89

Odpowiedz

23

Martin Fowler opisuje wzór Service Layer swojej wspaniałej książki Patterns of Enterprise Application Architecture. Jeśli zależy Ci na pytaniach takich jak ten, o który prosiłeś, powinieneś przeczytać tę książkę.

Jednym z zastosowań, który przychodzi mi na myśl, jest zarządzanie transakcjami bazy danych. Niektóre osoby próbują hermetyzować transakcje rozpoczynające i zatwierdzające w swoich modelach domen. Ale potem stają się zdezorientowani, gdy modele domen wywołują inne modele domen, które również próbują uruchamiać i zatwierdzać transakcje db. Który model naprawdę decyduje, czy transakcja została zatwierdzona czy wycofana? A co robisz, jeśli dany model jest używany na różne sposoby przez różnych klientów?

Warunkiem usługi jest Warstwa usług, ponieważ jest to warstwa, na której można uruchamiać i zatwierdzać prace obejmujące wiele modeli domen.

Co do tego, jak powszechne jest to, nie sądzę, żeby było to powszechne. Większość ludzi używających Zend Framework (lub jakiejkolwiek innej frameworki PHP lub Ruby) ledwo przeniosło się z "Active Record rozwiązuje wszystko" do nowego lśnienia, "Data Mapper rozwiązuje wszystko". Wygląda na to, że ta społeczność uczy się tylko jednego nowego wzorca co pięć lat. Przez jakiś czas nie przejdą do warstwy serwisowej.


Re komentarz od @ktutnik:

Nie, wzór Warstwa usług różni się od wzoru Repository. Repozytorium polega na abstrakcyjnym dostępie do bazy danych, dzięki czemu można korzystać z bazy danych, takiej jak Kolekcja. Warstwa usług dotyczy hermetyzacji złożonych operacji aplikacji.

Innym sposobem myślenia o nich jest ich związek z Modelem Domeny. Repozytorium jest używane między Modelem domeny a bazą danych. Natomiast Warstwa Usług wykorzystuje jeden lub więcej Domeny Modele.

Service Layer ---> Domain Model(s) ---> Repository ---> DBAL 
+0

jeszcze jedna rzecz, która zwykle mnie myliła .. warstwa usług i repozytorium ... czy to to samo czy inne myślenie? dzięki – ktutnik

7

Service layer rzecznictwo jest stosunkowo nowe i wciąż podlega różnym interpretacjom. Myślę, że oznacza to posiadanie warstwy, która wykorzystuje wiele modeli domen, które kontrolery wywołują (może jednak upraszczam to za dużo). Niedawno opracowaliśmy internetową korzystające z tego i praktycznych korzyści, jakie napotykane są:

  1. funkcje jak obsługa pomaga ze skalowalnością. Jeśli masz usługę obrazu, który początkowo korzysta z usług lokalnych zrobić to praca staje się łatwiejsza, aby ten punkt serwisowy do innego serwera lub jakiegoś 3rd party bez konieczności dokonywania zamiatanie aktualizacje

  2. elastyczność. W połowie projektu postanowiłem zmienić podstawowy element funkcjonalności i mogłem to zrobić bezboleśnie; pozwalając mi szybko zważyć zalety i wady aktualizacji. Ta elastyczność jest przydatna w przypadku szybkiego prototypowania i wpaja pewną pewność, ponieważ jeśli potrzebujesz czegoś ponownie, nie będzie to koszmar.

  3. Rozszerzalność. Zidentyfikowaliśmy już usługi w mojej aplikacji, które mogę przewidzieć w przyszłości dla innych programistów lub innych widgetów, aplikacji mobilnych.Teoretycznie jest to tylko kwestia dodania uwierzytelnienia i autoryzacji do usługi (ponieważ funkcje są już w jej własnej warstwie i nie muszę tracić czasu na próbę oddzielenia tego, co chcę ujawnić od reszty podstawy kodu).

  4. Usługi są łatwe do dodania i upuszczenia (być może należy to do jednego z wcześniejszych punktów). Mam usługi specyficzne dla określonego etapu projektu (np. Zapraszam tylko na etap), które mogę zrezygnować po zakończeniu tego etapu.

Myślę, że ma praktyczne zalety i kluczem do sukcesu w realizacji jest dobry sposób na zarządzanie usługami w aplikacji. Używam symfony dependency injection component

+0

Re # 2, czy możesz podać konkretny przykład tego, jak zmieniłeś ten element funkcjonalności (przed i po), aby łatwiej zrozumieć, w jaki sposób warstwa usług działa w praktyce? W punkcie 3 brzmisz, jakbyś mówił o interfejsie API, a # 4 brzmi jak system uprawnień. Nadal staram się zrozumieć, o co chodzi ta warstwa usługi i jak ją wykorzystać, więc może dlatego odrzucam te bardziej znane koncepcje. – jblue

+0

2. Przełączałem się z użycia solr na mysql iz powrotem bez większego wpływu na moje modele lub kontrolery. (w gruncie rzeczy czekam na doktrynę do implementacji monobitów doktryny, aby trochę dojrzeć, zanim to zrobię i dlatego wspomniałem, że pomaga budować zaufanie.) – Akeem

+0

3. Mówię o wykonywaniu niektórych z moich usług dostępne dla zewnętrznych twórców lub nawet własnych aplikacji mobilnych lub innych sposobów korzystania z treści.) – Akeem

0

See ZFEngine to CMF na ZF z warstwy usługa realizacji

Powiązane problemy