Lo scopo del pattern MVC è di ottenere la separazione della logica di dominio dall'interfaccia utente, seguendo il principio di Separazione dei dubbi :
In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).
Anche se questo è fantastico ed è magnificamente curato da CodeIgniter, non è abbastanza. Gli stessi principi si applicano ai singoli componenti della triade MVC (Modello, Vista e Controller). Le preoccupazioni dovrebbero essere il più separate possibile, è compito tuo identificare quali sono le preoccupazioni per la tua applicazione, ma se metti tutto in un controller e un modello probabilmente stai sbagliando.
Il schema MVC detta che l'unico lavoro del controllore dovrebbe essere:
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
Quindi non dovrebbe essere così grasso. Il suo compito è accettare l'input, convalidarlo e trasmetterlo al modello e / o alla vista. Come semplificazione eccessiva su quali potrebbero essere le preoccupazioni:
- Un controller dovrebbe rappresentare vagamente una pagina nel tuo sito web,
- Un modello dovrebbe rappresentare una tabella nel tuo database.
Quindi un controller dovrebbe essere preoccupato per una pagina e un modello per una tabella. Se il tuo sito web ha altre pagine oltre home , diciamo una pagina di contatto, dovresti prendere in considerazione un controller page . In questo modo sarà molto più facile per te connettere mentalmente parti della tua applicazione con il codice reale, e sarà di grande aiuto con la manutenzione. Separando il codice in parti logiche più piccole, il codice sarà più robusto e più facile da testare secondo il principio di Responsabilità Unica :
In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.
I numeri che hai nella tua domanda sono un po 'troppo. Non posso commentare tranquillamente se ciò che stai facendo potrebbe essere migliorato, dovresti pubblicare il codice effettivo per la peer-review all'indirizzo Scambio dello stack di revisione del codice .
C'è anche un piccolo problema di prestazioni. Ogni volta che si utilizza una classe, la classe viene caricata completamente. L'overhead è minuscolo, ma degno di nota.
Ulteriori letture:
Come suggerito da @melee nei commenti, dovresti cercare in CodeIgniter helpers , come un posto migliore dove mettere un sacco di funzionalità comunemente utilizzate. Puoi creare facilmente i tuoi aiutanti e avere alcune delle tue funzioni in loro e non nei tuoi controller. E dovresti conoscere gli hook per estendere facilmente il core del framework.