Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Ustalanie poziomów ograniczenia aplikacji
Forum PHP.pl > Forum > PHP > Object-oriented programming
Pyton_000
Witajcie.

W sumie temat chyba nadaje się najbardziej tutaj. Ale kto wie smile.gif Ja tam się nie znam.

Generalnie w głowie rodzi mi się pewien problem.

Szkic:

Mamy sobie napisany ładny skrypt sklepowy. Mniam mniam mniam. Jesteśmy z niego dumni. Powiedzmy że jest zrobiony w standardowej konwencji MVC. Modele pracują na dodawanie produktów do bazy, kontrolery ładnie pilnują aby nie było burdelu.

Teraz przychodzi do głowy, że może by naszą aplikację osadzić w SAAS.
Do tego chcemy zrobić np. 3 progi ograniczeń:
- prowizyjny (od zrealizowanych zamówień)
- do 1000 prod.
- unlimit

Najistotniejsza jest 2 opcja (do 1000 lub dowolna inna).
Ten limit to może być jeden z limitów bo np. dodawanie 2 obrazków do produktów itp.

Jak można w ciekawy sposób zrealizować takie ograniczenia aby jednocześnie system dbał o trzymane ramy dla danego planu, ale też możliwość łatwej zmiany.

Trzymać logikę w modelach? A może w kontrolerach i odpowiednio odpalać przed każdą akcją sprawdzając warunki.
To jest raczej dyskusja i pomysły które mogą się kiedyś przydać.


Zaznaczam że jest to temat stricte dyskusyjny i twórczy
adbacz
Ciężko będzie Ci napisać tak ten skrypt, być mógł w obojętnie którym momencie ustawić limit. Tak jak mówisz, albo na ilość produktów, albo na ilość zdjęć dla produktu, albo na coś innego. Ale wydaje mi się, że można tutaj zastosować coś z Eventów...

Tworzysz sobie "na kartce" listę możliwych limitów, jakie mogą być w tej aplikacji, chodzi o to by je jakoś nazwać, np. product.add, image.add itp. Teraz masz dwa wyjścia, albo łatwiej dla Ciebie bo edytujesz w jednym miejscu, albo troszkę więcej pisania ale masz większą kontrolę:

1. W routingu, tam gdzie masz odpalanie kontrolera robisz sobie jakiś dodatkowy parametr gdzie ustawisz jedną z tych nazw, którą wcześniej spisałeś na kartce. Teraz gdzieś w aplikacji wywołujesz zdarzenie onControllerBefore i jakiś tam Listener, którego podepniesz będzie nasłuchiwał. Następnie weźmie sobie z routingu, czyli aktualnej akcji kontrolera tą nazwę "z kartki", którą przypisałeć w tablicy routingu. I jak będzie miał ta nazwę to będzie mógł wydelegować zdarzenie do innej klasy/obiektu, który zajmie się dalej tym zdarzeniem.
2. W każdej akcji kontrolera wywołujesz jakieś konkretne zdarzenie, ale jako Context podajesz jedną z tych nazw które wcześniej wymyśliłeś.

W obudwu przypadkach powinieneś mieć jakiś Listener, który będzie nasłuchiwał zdarzenia onControllerBefore i delegował później w zależności od tego parametru z kartki do odpowiedniego miejsca w aplikacji. W tym miejscu będziesz sobie sprawdzał, czy może dodać ten produkt, czy to zdjęcie. Jeśli tak, to nie robisz nic, jeśli nie - zwracasz false, lub delegujesz dalsze wykonywanie aplikacji do kontrolera gdzieś E403 i tyle.

Oczywiście możesz też zrobić, zamiast listy tych nazw na kartce, listę Eventów: onBeforeProductAdd, onBeforeProductImageAdd itd. w tedy masz jeszcze troszkę mniej kodu, ale masz więcej zdarzeń.

I w tedy nie będziesz miał problemu z dodawaniem nowych limitów. W bazie danych gdzieś, lub w pliku konfiguracyjnym robisz sobie tablicę konfiguracyjną (musisz sobie to jakoś zgrabnie wymyślić) do której będą się odwoływać klasy obsługujące zdarzenia, by mogły sprawdzić, czy użytkownik może tą daną rzecz wykonać. A gdy będziesz chciał dodać jakiś inny limit? Dodajesz rekord do DB czy pliku conf. i obdługujesz jakieś inne zdarzenie, np onBeforePaymentPaypal i cała filozofia.

Prościej chyba się nie da wink.gif
Pyton_000
Zastanawiałem się też naz zrobieniem klasy która będzie odpowiedzialna za ustalanie czy dana operacja będzie możliwa czy nie.

Np. Klasa typu Restrictions która będzie sprawdzała na podstawie eventu czy jest możliwy do zrealizowania. Sama będzie dbała o pobranie konfiguracji pakietów.

Raczej zakładam że pakiety będą miały łączne ograniczenia np. 500 prod. i 2 zdjęcia/prod. i coś tam jeszcze. Tych ograniczeń może być mniej lub więcej.

To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.