Sono per lo più d'accordo con la risposta di Dime che vuoi creare i tuoi modelli per oggetto business - i problemi che l'azienda sta cercando di risolvere dovrebbero guidare come crei le classi modello. In pratica, ho scoperto che creare un modello per tavolo è un buon punto di partenza. È probabile che uno schema progettato correttamente imiti i processi aziendali necessari per modellare il codice dell'applicazione, chiamato anche Modello di dominio.
L'utilizzo di un layer Mapping oggetto / relazionale è utile in modo che il modello di dominio contenga le stesse relazioni dello schema del database senza la necessità di chiamate ripetitive a un livello di accesso ai dati. Controlla Eloquent per PHP come esempio. Sia lo schema che il modello di dominio dovrebbero essere progettati per supportare i processi aziendali.
Questo porta alla prima parte della risposta di Marjan Venema:
I's say that a model per table is just recreating your database in a class structure. It is known as a anemic model and considered an anti-pattern.
Un modello di dominio anemico è un anti-modello. Un "modello per tabella" come suggerisce Venema potrebbe essere visto come "ricreare il database", tuttavia è assolutamente scorretto affermare che solo questo è un modello di dominio anemico.
Da Martin Fowler:
The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters.
(enfasi, mia)
Il fattore chiave in un modello di dominio anemico è la mancanza di comportamenti o metodi nelle classi del modello di dominio.
That is because classes are intended to have both data and behaviour. If you restrict your models to a single table, where do you put the code (behaviour) that needs to deal with data and behaviour from multiple tables?
Ancora una volta, puoi e dovresti mettere il comportamento nei tuoi Modelli di Dominio, anche se si collegano solo a una tabella. Il comportamento che interessa più tabelle influisce davvero su più oggetti che si verificano mappare su più tabelle. Domain Driven Design è un approccio proprio allo stesso problema menzionato da Venema: "dove metti il codice (comportamento) che ha bisogno di trattare dati e comportamenti da più tabelle? "
E la risposta è un Root aggregato . Martin Fowler afferma:
Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.
(enfasi, mia)
Un "cluster di oggetti di dominio" può anche essere visto come "Modelli di dominio che si associano a più tabelle". Il comportamento che interessa più tabelle deve essere definito nella radice di aggregazione: una classe che incapsula la "cosa" che interessa più tabelle o oggetti:
Di nuovo, da Martin Fowler:
An aggregate will often contain mutliple collections, together with simple fields.
Per rispondere alla domanda originale dell'OP:
... would creating a Model per database table be considered good practice? That way methods aren't written twice.
Direi che questo è un buon punto di partenza, ma tieni presente che lo schema e il modello a oggetti non devono corrispondere al 100%. Il modello oggetto dovrebbe essere più interessato all'implementazione e all'applicazione delle regole aziendali. Lo schema dovrebbe essere più focalizzato sulla memorizzazione dei dati aziendali in modo modulare e scalabile.
Un modello per controller non sarebbe una buona pratica, sebbene esista una variante del modello chiamata View Model che fa si adatta al livello Controller. Un Visualizza modello è una riorganizzazione del modello di dominio per adattarsi a un certo tipo di visualizzazione, sia esso una pagina Web o un modulo in un'applicazione GUI.