Questo schema ignora il principio ASCIUTTA e posso modificare il motivo per adattarlo?

Question

Questo schema ignora il principio ASCIUTTA e posso modificare il motivo per adattarlo?

#1 da (1 voti)
#2 da (0 voti)

2

Ho appena iniziato a lavorare in un'azienda e attualmente stiamo svolgendo un programma di formazione abbastanza intenso (giorni lavorativi completi) per aggiornarci sul modo in cui l'azienda fa le cose e addestrarci in VB.NET , insieme ad alcuni C #.

Stanno iniziando a migrare verso un'architettura modificata Model-View-Presenter, con i remoting server che svolgono un ruolo abbastanza grande. Un programma .NET di esempio potrebbe assomigliare a questo:

SomeSolution
|
+-+- ServerProject
| |
| +- ServerEmployee.vb
| |
| +- Server.vb
|
+-+- Presenter
| |
| +- PresenterEmployee.vb
| |
| +- Presenter.vb
| |
| +- IView.vb
|
+-+- ViewProject
  |
  +- ViewEmployee.vb
  |
  +- View.vb

Le classi in questione sarebbero le classi dei dipendenti. L'esempio che ho ricevuto è che ServerEmployee avrebbe la maggior parte delle informazioni - essendo recuperato da un database, probabilmente avrebbe la maggior parte degli attributi, come .FirstName , .LastName , .MiddleInitial , .PreferredName , .HireDate e qualsiasi altro attributo fosse presente nel database. Il PresenterEmployee avrebbe gli altri attributi, nonché un attributo .FullName che forse è stato generato in questo modo:

If employee.PreferredName <> String.Empty Then
    employee.FullName = employee.PreferredName & " " & employee.LastName
Else
    employee.FullName = employee.FirstName & " " & Employee.MiddleInitial & " " & Employee.LastName
End If

E infine, ViewEmployee avrebbe solo gli attributi .FullName e .HireDate .

Siamo stati informati che la logica alla base di questo progetto era che, se abbiamo detto, una classe DataStructures a cui fanno riferimento le altre classi quindi ogni volta che la classe DataStruture deve essere ricostruita, l'intero progetto deve essere ridistribuito ( che capisco è un processo un po 'noioso a causa di alcune decisioni di infrastruttura). Capisco che non sarebbe A Good Thing ™, ma sembra che se hai un codice che probabilmente non cambierà molto (una superclasse abbastanza generica con alcune proprietà dirette), avrebbe senso evitare la duplicazione del codice.

Ho ragione nel ritenere che si tratti di una violazione del principio DRY? La prima cosa a cui ho pensato quando hanno insegnato questo è "ewww, che odora ..."

Altro che (potenzialmente) non dover ridistribuire l'intera applicazione ogni volta che viene modificata la superclasse, c'è qualche vantaggio nel fare le cose in questo modo? E se è rotto, e voglio prendere l'onere di provare a sistemarlo, quali sono alcuni buoni argomenti per difendere la mia scelta?

design code-smell

posta Wayne Werner 06.07.2011 - 20:06

fonte

2 risposte

1

Model-View-Presenter è una variante di Model-View-Controller. L'intento è quello di separare la visualizzazione e il contenuto in modo da poterne modificare uno senza modificare l'altro. Ciò semplifica anche la visualizzazione delle informazioni nel modello in più punti del tuo sito web e la sincerità della sincronizzazione.

Sì, c'è un lavoro extra, ci vuole un po 'di tempo per abituarci alla struttura, e c'è bisogno di sincronizzare i file tra i file. Ma ogni tanto ti ritrovi a fare un cambiamento facile e pensare: "Wow, sarebbe stato molto più difficile senza questa architettura!"

E i vantaggi di implementazione specifici per VB sono un'arma rossa in confronto a questo.

Ma essere avvisati - tutti i vantaggi della struttura possono essere persi se si indebolisce la struttura. È molto comune vedere i team mettere la logica nel posto sbagliato (ad esempio la logica di business nella vista), e una volta che è stato fatto, è molto difficile risolverlo.

risposta data 06.07.2011 - 20:41

fonte

Leggi altre domande sui tag design code-smell

è il linguaggio dei vincoli oggetto che vale lo sforzo? Qualcuno sa di webs.com?

score 0 · Accepted Answer

Una volta entrato nel mondo dell'architettura n-tier, diventa una questione di quanta separazione vuoi tra i livelli

Una tipica architettura a 3 livelli sarebbe Data Layer < - > Business Layer < - > Livello interfaccia utente.

Il livello dati conterrebbe le entità del database, il livello aziendale conterrà una vista delle entità del database con la logica aziendale applicata e il livello dell'interfaccia utente conterrà una vista del livello aziendale con la logica di presentazione applicata.

A seconda dello scopo del progetto, è perfettamente accettabile riutilizzare le entità tra i livelli se si desidera evitare un sacco di mappature ripetitive.

Si tratta davvero di separazione delle preoccupazioni rispetto a ASCIUTTO. Se è necessario riutilizzare il livello aziendale, ovviamente non si desidera che il livello dell'interfaccia utente utilizzi direttamente le entità aziendali, poiché qualsiasi refactoring dovrebbe essere applicato in più punti (è necessario ridefinire la stessa cosa in più punti considerando una violazione di DRY ? :)?

L'unica preoccupazione che avrei con l'approccio sopra è che non sono sicuro di come gestisci le entità aggregate. La mia preferenza è quella di utilizzare DDD per progettare il livello aziendale in modo che ogni componente sia destinato a uno specifico caso d'uso piuttosto che una semplice raccolta di entità separate con all'interno alcune logiche di business

Suggerirei uno strumento come AutoMapper per eseguire la mappatura tra i livelli tramite convenzione se si desidera la flessibilità dell'approccio di cui sopra, evitando al contempo alcune delle vostre preoccupazioni sull'asfalto.

In definitiva, non c'è una risposta giusta tho. : (