I framework MVC favoriscono il modello di dominio anemico al fine di evitare duplicazioni?

Question

I framework MVC favoriscono il modello di dominio anemico al fine di evitare duplicazioni?

#1 da (7 voti)

6

Legare direttamente il modulo al tuo modello aiuta molto a sbarazzarsi del codice della piastra, ma ciò significa che il tuo modello deve avere un getter / setter per ogni proprietà altrimenti non sarebbe possibile. Un'altra scelta sarebbe quella di creare un altro livello (DTO) solo per trasportare i dati da / verso il modulo e quindi è possibile avere un modello di dominio ricco non necessariamente con getter / setter per ogni attributo ma ciò significa duplicazione di campi e codice di convalida.

Ad esempio, in questo momento sto facendo un'applicazione per la posta elettronica. Sappiamo che abbiamo già l'API Java Mail, un buon modello di dominio ricco. Tuttavia, il modo in cui è progettato rende impossibile associare il mio modulo Web a quel modello. Sono costretto a creare un DTO per acquisire i dati e quindi passarlo all'API Java Mail. Proprio come in questo esempio se il mio modello di dominio fosse come questo, lo stesso accadrebbe.

Da documentazione Spring MVC :

Instead, it is often preferable to bind directly to your business objects.

Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them to extend a particular framework base class.

Fai framework web MVC come Spring MVC e Struts 2 , favorisci modello di dominio anemico per evitare duplicazioni?

domain-model mvc

posta Alfredo Osorio 12.08.2013 - 23:15

fonte

1 risposta

Leggi altre domande sui tag domain-model mvc

Modularità e "incapsulamento" in C Quindi sto sviluppando un flusso di lavoro con vagabondo + git ... ha senso?

score 7 · Answer 1

Nell'articolo di Martin Fowler che hai linkato, dice del Modello di dominio anemico :

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. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects.

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.

Tuttavia, detto questo, dice anche questo:

Putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.

Qui è dove Visualizza i modelli entra.

Visualizza i modelli contengono due cose:

Tutti i dati necessari per l'esecuzione di una vista e
Qualsiasi logica richiesta per il rendering della vista, ma che può essere reinserita nel ViewModel, piuttosto che ingombrare la vista.

Se ViewModel non contiene alcuna logica, allora potrebbe essere correttamente chiamato un modello anemico. Ma non è un modello anemico del dominio. Sebbene possa contenere dati provenienti da oggetti di dominio, l'unica ragione di esistenza dell'oggetto ViewModel è di separare la logica di dominio dalla presentazione, proprio come osserva Fowler.

La disposizione risultante rende molto più semplice concentrarsi sul layout e sull'interazione dell'utente nella vista, senza preoccuparsi di come tale interazione possa inquinare gli oggetti del dominio e la loro logica, o viceversa. È lo strato di separazione descritto da Fowler.

Vedi anche
Il modello del modello di vista
Non è MVC Anti-OOP?