Witam,

Pracuje na FW CodeIgniter i z góry mam narzucony MVC więc też tak się też uczyłem. Ale zauważyłem, że łatwiej mi było napisac bibliotekę z funkcjami do połączeń z bazą danych , do których wysyłamy m.in. nazwę tabeli, kolumnę w której szukamy, czego szukamy, limit i początek pobierania elementów.

Na początku oczywiście stosowałem wszystkie założenia MVC. Kontroler i widok w CI to raczej normalka, ale zauważyłem, że obywam sie bez modeli i jakos nie widze znacznych problemów w pracowaniu nad taką stroną. Dodam też, że już kilka razy zdarzyło mi się przeglądać taki kod bo musiałem coś zmienić lub dodać i nie było żadnych problemów.

Teraz całe sedno.
Dostałem propozycje pracy w pewnej firmie i chodzi mi własnie o te modele. Nie chciałbym robic tego wszystkiego pod siebie bo jesli dojdzie do tego, że zastąpi mnie ktos inny to żeby nie miał problemu z czytaniem mojego kodu. Kiedyś (bez tej biblioteki DB) miałem osobny model do każdego kontrolera. A każdy kontroler był jakby osobną funkcjonalnością serwisu. Czy to tak właśnie ma wyglądać? Że mamy powiedzmy 10 kontrolerów a do tego 10 osobnych modeli? Wg mnie to marnotrawstwo naszego czasu i palców bo jesli mi dobrze się pracuje z taką biblioteką do połączeń z DB to po co miałbym pisać każdy model i to jeszcze tak, że każdy jest prawie taki sam.

Troszkę nalałem wody ale mam nadzieje, że mnie zrozumiecie.
Co o tym myślicie?

tak to ma wyglądać.

Ew. zawsze możesz napisać model po którym będziesz dziedziczył (z tą klasą którą sobie napisałeś do obsługi db) i nie będziesz musiał pisać wszystkiego od nowa, tylko wywoływał odpowiednie metody z odpowiednimi parametrami.

@k_@_m_i_l pamiętaj że model to nie tylko wybieranie danych z bazy, to pobieranie danych ze xml/json/xls/database jak również walidacja danych które umieszczasz w tym wszystkich o czym pisałem wcześniej.

@skowron-line: tak tak, ja o tym pamiętam, wiem że model służy do obróbki wszelakich danych, aczkolwiek w tamtym poście odniosłem się do konkretnego przypadku o którym wspomniał @adbacz

Nie musi zachodzić równość: ilość kontrolerów = ilość modeli. Szczerze mówiąc, to zazwyczaj wygląda to tak: ilość kontrolerów < ilość modeli.
Modele można podzielić na te, które odpowiadają za funkcjonalność aplikacji np. walidatory, logery, translatory etc. oraz na te, które reprezentują obiekty świata rzeczywistego np. Product, User etc. Te drugie zazwyczaj są również w jakiś sposób zapisane np. w bazie danych.
Rozumiem, że pytasz o zasadność tworzenia tych drugich, tak?
Co prawda może Ci się wydawać, że jest to niepotrzebne powielanie kodu, ale wszystkie te klasy w pewien sposób reprezentują obiekty realne i ułatwiają odnajdywanie się w logice aplikacji.
Oczywiście można napisać:

[PHP] pobierz, plaintext 
//dodawanie
$insertId = Db::insert('product')->(array('name', 'price'), array('orange', '1.99'))->execute();
 
//pobieranie
Db::select('product')->where('id = ?', 1)->execute();
[PHP] pobierz, plaintext 

ale można też tak:

[PHP] pobierz, plaintext 
//dodawanie
$product = new Product();
$product->name = 'orange';
$product->price = '1,99';
$product->save();
 
//pobieranie
$product = ProductTable::getById(1);
[PHP] pobierz, plaintext 

Oczywiście i jedna i druga forma jest poprawna, ale ta druga na już na pierwszy rzut oka pokazuje co się dzieje, natomiast w przypadku pierwszej trzeba przeanalizować zapytania ubrane w obiektówkę.

Dzięki za wytłumaczenie. Ja jak na razie oprócz database to w modelach nic nie robię. No może trochę jesli chodzi o edycję, upload plików. Jestem początkujący więc jak to początkujący "sprawdzam własne teorie" by po nieudanych próbach zacząć pisać poprawnie

To nie jest dobre podejście, bo odejście od złych nawyków jest czasami bardzo ciężkie.
Kontroler jest łącznikiem między danymi klienta, a tym co się dzieje w corze aplikacji i nie powinien zawierać żadnej logiki. Na początku może być trochę ciężko z zastosowaniem tego w praktyce, ale naprawdę warto. Ułatwia to późniejsze zmiany w kodzie.