Niech istnieje pewna aplikacja w php implementująca MVC. Niech dane przechodzą drogę: <form> zostaję wysłany przez użytkownika, pewne reguły walidacji zawarte gdzieś w aplikacji, ostatecznie trafiają pod jakąś postacią do bazy danych.

I tu pojawia się problem. Reguły dotyczące logiki i poprawności tych danych niestety znajdują się w kilku miejscach. Po pierwsze w samej bazie utworzone kolumny mają jakieś typy, po drugie (np. w kontrolerze akcji) istnieją bardziej szczegółowe zasady walidacja (np. min n znaków, tylko alfanumeryczne etc) o jakiś ustawieniach no i w widoku trzeba pamiętać aby poprawnie skonstruować cały <form>. Strasznie to męczące i trzeba pamiętać o każdym z tych elementów.

Czy znacie jakieś gotowe rozwiązanie które pozwoliło by to wszystko spójnie połączyć? Nawet kosztem tworzenia kolejnej warstwy w aplkiacji. Coś co zapewniłoby ujednolicenie tego wszystkiego.

Jak należałoby do tego podejść. Na razie przychodzą mi do głowy dwie rzeczy:
1) Albo próbować tworzyć jakiś ORM w PHP, który pozwoliłby na złożenie wszystkich reguł poprawności danych w jednym miejscu (XML?)
2) Przenieść maksymalną ilość zadań na samą bazę danych, poprzez np. procedury wbudowane i triggery.

Co lepsze? A może wogóle jakieś inne podejście? Proszę o opinię.

no wlasnie tez sie zastanawiam jak powinna wygladac architektura przeplywu informacji.

Mam strone oparta o smarty. Tam jest formularz.

Po dokonaniu formularza nastepuje jego walidacja.
Jezeli wszystko ok to wykonywana jest akcja podpieta pod formularz - np. rejestrowanie + przekierowanie na strone z komunikatem.
Jezeli ktorys parametr jest zle wpisany to powrot na strone formularza + wyswietlenie bledow.

Moje pytania to:
1. gdzie powinny byc zaimplementowane komunikaty bledow ? W Smarty, czy przekazane w tablicy do -> Smarty.
2. Przegladajac kiedys to forum, znalazlem linka do klasy walidujacej formularz, ktora bardzo mi sie spodobala, a ktorej
nie moge teraz znalezc. Jaka klase najlepiej uzyc (z dostepnych) do walidacji formularzy. Czy jest cos lepszego od tej udostepnionej w PEAR ?

w smarty implementujesz sobie taki prosty kodzik

{if $error}
<div class="error">{$error}</div>
{/if}


i w metodzie danej tam klasy sprawdzajacej formularz sprawdzasz pola, jeśli coś jest nie tak przypisujesz to do zmiennej $error. Pod koniec funkcji sprawdzasz, if($error) $smarty->assign('error', $error); i przypisujesz ten błąd ze zmiennej i wyświetlasz, jeśli wszystko pojdzie ok to inny warunek i inny display.

Jeśli masz dostęp do skryptu AbleSpace, to przejrzyj tam kod, jest świetnie napisany i super wykorzystuje model MVC, w tym wielokrotne wykorzystanie tego samego pliku szablonu ale segmentarycznie (layers).

pozdro

Moim zdaniem to nie jest wada, że sprawdzanie poprawności danych (walidacja) jest wykonywana na kilku poziomach. Każda z warstwa ma bowiem inne zadanie. W pierwszej kolejności baza danych, struktura bazy powinna zapewniać jak największą kontrolę spójności danych poprzez stosowanie ograniczeń (constraints) kluczy (primary keys, foreign keys) oraz kontroli danych (typy pól, unique constraints, trigers, stored procedures). To zapewnia kontrolę spójności na pierwszym poziomie (najważniejszym - ponieważ dane powinny być logicznie spójne). Powstaje natomiast problem przekazywania informacji do aplikacji co do jakości błędu, nie do samego jego wystąpienia lecz do tego jaki błąd wystąpił oraz jakie są np. poprawne wartości. Jak to przekazać do aplikacji aby ta właściwie poinformowała o tym końcowego użytkownika?

W aplikacji stosuję warstwę pośredniczącą pom. obiektami (tabelami) bazy danych a aplikacją (np tabela produkt i klasa DBProdukt - u mnie to jest generowane półautomatycznie ale nie wnikam w szczegóły). Klasa ta zapewnia drugi poziom walidacji kontrolując podstawowe dane takie jak typ, zakres, maska, not null itd dla danych (można to sprowadzić do kontroli danych na poziomie jednego pola bez powiązań). Warstwa ta nie jest odpowiedzialna za wystawiani komunikatów użytkownikowi.

Jest również kolejna warstwa, która waliduje dane pod względem logicznym włączając w to powiązania pom. polami takie jak data 1 nie może być większa niż data 2 itp. Stosuję tutaj 2 rozwiązania. Albo zawieram takie powiązania w osobnej klasie walidatora albo mam to w klasie vidoku - nieistotne. Ta warstwa jest odpowiedzialna za pierwsze (po poście) - wstępne zwalidowanie popranwości pól począwszy od typu, zakresu, maski, aż do powiązań i walidacji logicznej pól. W zasadzie przepuszczenie błędu przez tą warstę skutkuje bądź to wywaleniem się aplikacji w drugiej warstwie (DBProdukt) albo ostatecznie wywaleniem się bazy. Ta warstwa również dokłądnie wie jaki błąd wystąpił i jaki (czytelny) komunikat ma wyświetlić użytkownikowi.

Dzięki temu zapewniam sobie mocną kontrolę danych. Mimo tego, że mam z tym sporo pracy, uważam że wysiłek się opłaca. Klasy DB (DBProdukt) używam w wielu miejscach gdzie nie zawsze stosuję te same reguły logicznych powiązań.
Należy tworzyć taki kod walidacji aby można go był wykorzystać w innych miejscach aplikacji, aby przy zmianie reguł nie poprawiać ich w 100 miejscach tylko w jednym.

Należy jednak pamiętać o kilku zasadach:
- baza danych to świętość - należy tak ją konstruować aby była maksymalnie spójna w każdej sytuacji
- kontrola danych na poziomie podstawowym (typ, maska, zakres)
- kontrola danych logiczna - powiązania logiczne pól w określonej sytuacji (kontekście aplikacji)
- ! starać się tak pisać kod reguł aby był do wykorzystania w innych miejscach aplikacji a nie pisane zawsze od nowa (a poprawiać tylko raz)

Pozdro