Ciò che è buono (pulito) architettura nella programmazione di un semplice sito web, ad es. un libro di contatto?

Hai sollevato una domanda molto interessante e fondamentale. La domanda riguardante l'architettura del progetto su larga scala e l'organizzazione della struttura delle cartelle (che è secondaria all'architettura).

Oggi l'approccio più comune alla costruzione dell'architettura del framework CMS è l'utilizzo del pattern MVC. Ci sono alcuni buoni articoli su come costruire i propri framework MVC, uno di questi è Crea un framework MVC con PHP .

MVC sta per Modello, Visualizza, Controller. Puoi chiamare questi approcci come preferisci: MVC, HMVC, MVP. L'essenza è isolare i singoli componenti del tuo sistema. Il "Controller" recupera i dati dal "Modello" e li invia a "Visualizza", che esegue il rendering dell'HTML finale. Hai già implementato la "V" nella tua contacts.php e "MC" nella tua contacts_class.php . Quindi hai isolato la vista dal modello e dal controller. Ora puoi facilmente cambiare la tua "vista" lasciando intatte le altre parti.

Non ti sto suggerendo di seguire ciecamente MVC, MVP o qualsiasi altro pattern "MV". È questione di appropriatezza, efficacia e gusto.

L'applicazione web del sito web comune può includere componenti come:

• Il punto di ingresso, ad esempio index.php
• Le librerie / classi helper
• Il router di richiesta
• I moduli, i componenti o i controller
• Il motore del modello o forse singole viste

La vera applicazione web può includere qualsiasi altro componente come gestori di eventi, dispatcher di eventi e hook, ma queste sono in realtà sfumature. Bene, permettimi di presentarlo nel modo in cui voglio presentarlo:

La routine di funzionamento del framework comune come segue:

1. La richiesta del browser viene inviata direttamente all'eseguibile / script del punto di ingresso ( index.php ).
2. Lo script del punto di ingresso carica le librerie helper, le classi e esegue un'ulteriore inizializzazione del nostro ambiente di programmazione.
3. L'URL viene passato all'istanza del router di richiesta. Questo passaggio può essere la parte del passaggio 2.
4. Il router di richiesta analizza l'URL e invia l'operazione a un particolare componente, modulo o controller.
5. Il componente (o controller) elabora la richiesta indirizzata e invia i dati alla vista da rendere.

La struttura della cartella del progetto corrispondente è mostrata nel diagramma.

Ti suggerisco di indagare su come sono implementati gli altri framework. I CMS / framework consigliati per iniziare sono CodeIgniter, OpenCart, Joomla 1.5 e Tango CMS.

Per avere un'idea di quali domande porre e quali soluzioni sono disponibili, raccomando i Modelli di Enterprise Application Architecture libro di Martin Fowler. Puoi avere un'idea di cosa c'è nel libro leggendo il suo sito web

Tieni presente che il libro è già piuttosto vecchio (in IT land), ma molti principi sono ancora validi o dovresti imparare da cui imparare. (Aveva senso?)

(Software) L'architettura è un argomento molto vasto, non aspettatevi una pallottola d'argento, ma sempre più domande e più dubbi fino a quando tempo e denaro finiranno e dovrete seguire la migliore soluzione finora.

Prima di tutto, dai un'occhiata a un progetto ben sviluppato. Wordpress è un ottimo esempio di struttura del codice: è semplice da capire ma offre un sacco di "plug". Quindi wordpress è facile da estendere tramite "plug in".

In secondo luogo, un modo molto semplice per controllare la tua architettura sta cercando di scrivere un test unitario. Ad esempio se la classe "Mazzo di carte" ha un metodo "shuffle ()", devi essere in grado di creare un mazzo di carte di dimensioni predefinite (cioè 5 carte 1,2,3,4,5), chiamare shuffle e verificare in un modo semplice il risultato (id 1,4,2,5,3)

Devi essere in grado di farlo senza istanziare l'intera classe del progetto e il test deve essere molto pulito da leggere.

Se non puoi farlo, devi aggiungere livelli tra le classi, ristrutturarli, fino a ottenere un modo semplice per farlo.

Quindi reifica questo passaggio per tutte le classi principali del tuo progetto.

Ultimo ma non meno importante: una buona architettura può essere "pigra" per le classi non-core (è una questione di economia: le cose progettate molto bene costano troppo nel mondo reale).

Una buona architettura per progetti su larga scala è MVC (Model View Controller): link

Se altri programmatori capirebbero che è una questione completamente diversa, comunque. MVC può diventare complesso ed a volte eccessivo per piccoli progetti. Uno dei vantaggi di questo è che si adatta facilmente.

Se comprendo correttamente la tua domanda, stai parlando della struttura delle cartelle del progetto e non essenzialmente di un'architettura. Se la mia comprensione è corretta, continuate a leggere; altrimenti modifica la tua domanda o metti un commento e modificherai la mia risposta di conseguenza.

Durante la progettazione di un'applicazione, dopo aver risposto ad alcune domande di base come (cosa? ea chi?), è necessario identificare i componenti e classificarli in base a funzionalità \ responsabilità. Ci sono due modi principali che conosco. È possibile classificare i componenti in base, utilizzare i casi che gestiscono (come login, ricerca, ecc.) O classificare in base alle risorse (oggetti ...). Il primo è chiamato Activity oriented e il secondo è chiamato Resource Oriented. Tradizionalmente la maggior parte delle applicazioni classifica i componenti in base alle attività (poiché i progettisti l'hanno trovata, è facile trasferirsi dal dominio problematico al dominio della soluzione). Ma io divago.

Una volta identificata la classificazione dei componenti, è necessario identificare la classificazione in base ai livelli. Una tipica applicazione Web avrà View Tier, Model Tier e Controller Tier (MVC). Naturalmente potrebbero esserci anche applicazioni più complesse. (La maggior parte delle applicazioni del mondo reale sono più complesse di quanto sia semplice).

Dopo aver identificato queste due tassonomie, creerò le cartelle di livello superiore Identificando ogni livello. (UI, Controller, Servizi, Utils ecc.). Sotto ogni cartella di alto livello creerò cartelle figlio basate su Funzionalità o Risorse (Progetto - / Progetto Edit - / Progetto di ricerca ecc.). La classificazione idealmente funzionale sarà multilivello.

Ci sono buone architetture e cattive architetture, tuttavia non ci sono proiettili d'argento. Un'architettura deve essere adeguata ai requisiti futuri attuali e altamente possibili.

Una buona guida sarebbe, assicurati che ogni parte dell'applicazione possa essere cambiata con un effetto minimo sulle altre parti e che ogni parte abbia automatizzato i test completi di integrazione e unità di copertura.

L'architettura riguarda il fatto di poter continuare a sviluppare a lungo termine. Per le applicazioni più grandi, questo include il compromesso tra il rendere le cose indipendenti, in modo che più persone possano lavorare simultaneamente ed evitare la duplicazione (DRY) in modo che il progetto possa rimanere agile. I progetti PHP tendono a concentrarsi sul rendere le cose indipendenti e hanno una grande quantità di duplicazioni.

Per avere un buon feeling con l'altra posizione estrema, dai un'occhiata a Seaside

Se non sai come strutturare un progetto di grandi dimensioni, devi prendere in prestito la progettazione / l'architettura di altri utilizzando uno dei numerosi buoni framework PHP. Consiglierei CakePHP, CodeIgniter o Symfony. Tutti questi implementano un patten Model, View, Controller, MVC che funziona bene nello sviluppo web, sono tutti abbastanza leggeri e facili da imparare.

Una volta che conosci uno di questi framework, potresti essere in grado di progettare la tua struttura per il tuo particolare progetto, ma se sei appena agli inizi mi occuperei del lavoro degli altri e reinventerò la ruota.

MVC è l'architettura più comunemente utilizzata, che ha dimostrato di risolvere la maggior parte dei problemi. Una buona architettura avrà le seguenti caratteristiche (e altro ancora, orcourse)

1. Può essere testato unitamente
2. Separazione delle preoccupazioni
3. Più persone saranno in grado di lavorarci senza alcuna collisione.
4. Può essere esteso senza molti problemi
5. Può essere scalabile. Quando si tratta di grandi progetti, la scalabilità sarà una delle maggiori preoccupazioni. Checkout Kohana framework, che è ben scritto e può essere ridimensionato molto bene

prima di scrivere qualsiasi codice di produzione, prendi 2 settimane (notti :) e leggi questo libro. Cambierà idea a lungo sulla programmazione dell'architettura, delle pratiche e del packiging.

Principi, modelli e pratiche agili C # di Prentice Hall

Gli esempi sono in C # ma sono facili da leggere, non si tratta di come scrivere la sintassi corretta del codice, ma di come pensare come programmatore.

Ti prometto che lo salverai sul tuo posto più accessibile sul tuo pc e rimarrai sorpreso che hai programmato senza averlo saputo. Sposterà il tuo pensiero.