Modelli per tabella di database?

9

Sto usando il codeigniter e mi sono trovato in una situazione simile in cui ho ripetuto i metodi Model. Sto creando un modello per controller. Ma vorrei creare un modello per tabella di database da considerare una buona pratica? In questo modo i metodi non vengono scritti due volte.

Invece del modello per controller o diversi piccoli modelli condivisi.

Esempio se ho un metodo modello get_user ($ user_id) Potrei scriverlo su users_models.php ...

Uno degli aspetti negativi che vedo di questo è che potrei dover chiamare diversi modelli, piuttosto che controllername_models.php.

Il caricamento di diversi modelli in cui diversi metodi potrebbero non essere utilizzati da un controller influisce sulle prestazioni e sulla velocità? Quale potrebbe essere il modo migliore per affrontare questo problema?

Nota: ci sono domande simili, ma non coprono la base della tabella Modello per database.

    
posta Howard Steff 13.03.2012 - 02:34
fonte

3 risposte

8

Suppongo che un modello per tabella stia semplicemente ricreando il tuo database in una struttura di classe. È noto come modello anemico e considerato un anti-modello. Questo perché le classi hanno lo scopo di avere sia dati che comportamenti. Se limiti i tuoi modelli a una singola tabella, dove metti il codice (comportamento) che ha bisogno di trattare dati e comportamenti da più tabelle? I tuoi controller avrebbero quindi bisogno di modelli che utilizzano uno o più di questi modelli "table" ... Quindi, a parte la più semplice delle app, guadagni poco o nulla da questo approccio.

    
risposta data 13.03.2012 - 09:29
fonte
6

In generale, è necessario creare i propri modelli non per tabella o per controller ma per oggetto di business. A volte può essere una relazione 1: 1 con la struttura delle tabelle o con i controller, ma non è necessaria.

Nel tuo esempio potresti avere una classe users_model chiamata da diversi controller. Questo va bene e talvolta anche desiderabile. Tuttavia nella maggior parte dei casi la classe users_model otterrà i suoi dati da diverse tabelle.
Ad esempio, la proprietà last_login_date della classe users_model può ( non deve ) essere ottenuta da una tabella user_audit separata con relazione uno-a-molti con il% co_de principale % tabella.

E direi che se hai una tabella SQL per oggetto business, è molto probabile che la struttura del tuo database non sia normalizzata.

    
risposta data 14.03.2012 - 14:47
fonte
3

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.

    
risposta data 03.03.2016 - 19:44
fonte

Leggi altre domande sui tag