Modelli: due concetti molto diversi

Un problema con queste discussioni è il mixaggio tutt'ora frequente di diversi punti di vista architettonici nella stessa discussione o diagramma.

• Alcuni punti di vista architettonici sono pensati per mostrare profondità: approfondimenti su come vengono implementate alcune funzionalità particolari.
• Mentre altri punti di vista architettonici sono destinati a mostrare l'ampiezza: le interazioni di componenti che sono pari (che esistono allo stesso livello in termini di profondità).

La combinazione di entrambi i punti di vista (profondità e larghezza) insieme nello stesso diagramma tende a creare confusione. Nel rilevare le fonti citate, trovo che non ci sia carenza di questo tipo di miscelazione di questi elementi che sarebbero idealmente separati da punti di vista architettonici.

Ad esempio, il diagramma che stai mostrando (citando Microsoft), hai detto che MS afferma di essere un diagramma MVC, ma sta principalmente mostrando la profondità nel modello di dominio, con un focus eccessivo sulla persistenza (dal punto di vista MVC) . Quindi, questo diagramma è debole sull'ampio punto di vista dei peer interagenti (M, V, C) e si mescola in alcuni punti di vista di profondità con persistenza: scomposto (ed elevato per essere un peer degli altri componenti). È comprensibile che si possa mettere in discussione dove la logica di dominio appartiene ai punti di vista architettonici "tutti-da-facile-a-mix".

In MVC, il modello è ciò che è responsabile della gestione degli oggetti di dominio, rispondendo alle query e ai domini orientati al dominio comandi (inclusa la convalida, ecc.) e l'applicazione / esecuzione di regole e ampli orientati al dominio comportamenti. MVC non parla di persistenza irrinunciabile: se il tuo sistema include persistenza che è un dettaglio di implementazione (dettaglio di profondità, non di larghezza). Pertanto, non ci sono dubbi su dove la logica di dominio appartenga a MVC, o se gli oggetti di dominio siano stupidi o intelligenti - queste domande sono tutti aspetti interni (dettagli di implementazione) del modello.

Hai anche ragione sul fatto che il termine Modello sia sovraccarico e sovrautilizzato. Quindi, ciò che il termine significa deve essere valutato in qualche contesto. Sfortunatamente, molte di queste discussioni non riescono a impostare o mantenere il contesto, aggiungendo confusione.

In MVC, il termine Modello indica ciò che ho menzionato sopra (custode di oggetti dominio, gestore di query e comandi ...). Potremmo parlare di POJO, e tale discussione dovrebbe applicarsi alle interazioni tra i peer M, V, C e se la query & l'interfaccia di comando per il modello utilizza oggetti più intelligenti o più intelligenti.

Nel dettaglio della persistenza - un dettaglio di implementazione dal punto di vista di MVC - possiamo parlare a POJO, o smart / stupido in diversi punti del meccanismo di persistenza, possiamo anche riutilizzare il termine modello su diverse interfacce nei dettagli di implementazione della persistenza.

In sintesi, è possibile utilizzare il termine modello in entrambi i modi che stai descrivendo, non è né / né. Ciò che rende le cose confuse è che spesso non riusciamo a impostare il contesto e / o non riescono a mostrare quando spostiamo il contesto dall'ampiezza (l'interazione dei componenti peer) alla profondità (dettaglio dell'implementazione di solito di uno di questi componenti).

In MVC, il modello è tutto ciò che non fa parte della vista o del controller. In MVVM, il modello è tutto ciò che non fa parte della vista o del ViewModel. Dovrebbe essere abbastanza facile da ricordare.

Se quella definizione non ti soddisfa, pensa al modello come tutti quei componenti che riguardano direttamente il tuo dominio problematico, come una classe Cliente o una classe Invoice. Tutto il resto fa parte di un'astrazione dell'interfaccia utente, ovvero MVC e MVVM lo sono davvero.

In altre parole, MVC e MVVM in realtà non hanno nulla da dire sul modello, da una prospettiva architettonica. La struttura e l'organizzazione del Modello dipendono interamente da te; MVC e MVVM si preoccupano principalmente con gli altri componenti (vista, modello di vista, controller).

Ulteriori letture
Modello di dominio da Wikipedia

Il modello non è "tutto il resto". Il modello è il numero dietro 3.14159 ... Non è "3.14159265". Non è il pulsante che premi per ottenere pi. Non è la carta su cui scrivi π. Non sono le luci intermittenti che usi per comunicare il rapporto tra circonferenza di un cerchio e diametro. È il numero, tuttavia si sceglie di modellare quello, che si utilizza quando si calcolano altre cose divertenti come onde, pneumatici rotanti e testo ruotato.

Ora certo, mezzo tau è solo una costante stupida che puoi estrarre da una libreria, ma il punto è che devi decidere come modellare le cose in base alle esigenze di modellazione. Questo è il modo in cui la tua applicazione pensa al mondo. Ecco cos'è un modello. Come mostrare, manipolare, ricordare, comunicare o qualsiasi altra cosa oltre alla modellazione non è il lavoro dei modelli.

È possibile inserire regole di business nel modello. Ma quelle regole dovrebbero essere meglio di modellare qualcosa. Non altro

Se seguire queste regole significa che non hai dove mettere qualcosa di bello. Crea qualcosa di nuovo per tenerlo. Farai un pasticcio empio se seguirai ciecamente i disegni preconfezionati piuttosto che presti attenzione a ciò che il tuo problema ti sta dicendo di cui hai bisogno.

Nel chiarire il termine Modello, iniziamo con le definizioni nelle note originali di Trygve Reenskaug sul concetto MVC scritto nel 1979.

A Model is an active representation of an abstraction in the form of data in a computing system.
Thing-Model-View-Editor

Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.
Models-Views-Controllers

Nei commenti che seguono la definizione di un modello nel primo documento, Reenskaug fornisce una descrizione di come il modello dovrebbe essere rappresentato in un computer.

The models are represented ... as a collection of data together with the methods necessary to process these data.
Ideally, all models should be totally consistent.
Thing-Model-View-Editor

Reenskaug sembra definire due concetti con una sola parola. I modelli sono sia un'astrazione da rappresentare nel computer sia una rappresentazione di un'astrazione. Occorre fare una distinzione tra questi: il modello come astrazione e il modello come rappresentazione di tale astrazione.

Un'altra descrizione è offerta da Steve Burbeck nel suo articolo che fornisce informazioni essenziali per i nuovi programmatori Smalltalk-80.

[T]he model manages the behavior and data of the application domain
How to use Model-View-Controller

che considera anche il modello come una rappresentazione attiva.

Nel 1980 fu pubblicato per la prima volta un articolo di Ted Codd. In esso un modello di dati è definito come ...

...a combination of three components:

1. a collection of data structure types (the building blocks of any database that conforms to the model);
2. a collection of operators or inferencing rules, which can be applied to any valid instances of the data types listed in (1), to retrieve or derive data from any parts of those structures in any combinations desired;
3. a collection of general integrity rules, which implicitly or explicitly define the set of consistent database states or changes of state or both.

Data Models in Database Management

Chris Date ha anche definito un modello di dati come ...

...an abstract, self-contained, logical definition of the objects, operators, and so forth, that together constitute the abstract machine with which users interact. The objects allow us to model the structure of data. The operators allow us to model its behavior.
An Introduction to Database Systems (Eighth Edition)

In queste definizioni un modello di dati è un'astrazione formale. I componenti corrispondono a quelli che gli stati Reenskaug dovrebbero comprendere il Modello da rappresentare nel computer. Pertanto, si conclude che un modello come astrazione è un modello di dati.

Un DBMS implementa un modello di dati. Permette agli utenti di creare una struttura di tipi di oggetti; creare o utilizzare una raccolta predefinita di operatori per elaborare tali dati; e dichiara e / o implementa i vincoli per assicurare che i dati siano coerenti. Pertanto, si conclude che il Modello come rappresentazione di un'astrazione, ovvero il componente Modello di un framework MVC, è un DBMS.

Per quanto riguarda le tue domande:

1. Sento che ti manca qualcosa con entrambi i concetti forniti sui modelli.

2. In alcuni casi, questi altri nomi non sono necessariamente allo stesso livello del modello, ma possono essere elementi del modello.

Questo non vuol dire che ci sono casi in cui le distinzioni che vedi semplicemente non accadono.

Ho alcune cose che cerco di tenere in prospettiva quando mi avvicino a una specie di modello.

Dal modello stesso:

• che cosa dovrei (la modella) conoscere di me stesso?

  • qualcosa di simile dovrei sapere la mia posizione se creo una lista di cose, o dovrei sapere gli articoli / formula / vincolo usati per definire il mio valore esposto

Da tutto ciò che chiama il modello:

• Fornisco i risultati di una formula / vincolo al modello o dovrei essere agnostico su come è stato determinato il risultato?

  • qualcosa come posizione (x & y, o qualche gruppo di contenitori) per determinare un valore o una regola derivata che il modello non ha bisogno di analizzare / determinare

Quindi, ci sono casi in cui diversi elementi della logica aziendale si trovano in un posto a cui non appartengono, ma ciò dipende in realtà dall'intento generale di alcune app o domini che possono ancora cambiare nel tempo.

Per il concetto di nomi migliori, la ragione per affermare se qualcosa come servizio o repository non è necessariamente sullo stesso livello è per lo stesso ragionamento sopra indicato.

• Come servizio, è il mio risultato qualcosa che è usato per essere il modello, o sono abituato a ricavare qualche altro valore associato al modello?

Facciamo un passo indietro.

Indipendentemente da tutte le altre definizioni distrattive della parola, nella tecnologia un modello è un'immagine realizzabile di un problema, un'analogia, qualcosa che ti permette di comunicare su una creazione. Ci possono essere molti modelli per la stessa cosa che tutti hanno senso. E un modello può funzionare per più di una cosa. Come un albero con uno stelo e rami è un modello che funziona per un sacco di materiale tecnico.

Nella modellazione software, il modello è spesso una parte non specificata del sistema. Non è specificato perché è diverso per ogni applicazione. E quindi confuso. Hai il tuo database (piuttosto concreto, chi non ne ha uno?), Hai la tua interfaccia utente (va bene, so di cosa si tratta), e poi hai qualcosa in mezzo che spetta a te definire e risolvere, che è il cuore della tua applicazione, che rende la tua applicazione diversa dalle altre applicazioni che seguono gli stessi principi di progettazione. Quello sarebbe il tuo "modello".