Costruire il livello di presentazione direttamente sul livello dati

Question

Costruire il livello di presentazione direttamente sul livello dati

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

2

La mia applicazione al momento è piuttosto caotica e sto cercando di districare tutto. La mia idea attuale è che dovrei avere 3 livelli separati:

livello dati che sa come conservare elementi nel database (e gestire le modifiche allo schema dati, quindi non è così banale)
domain layer (è quel nome corretto?) che fa tutto il magico cambiando gli oggetti ed elaborando gli eventi innescati dalle richieste degli utenti
livello di presentazione che sa come mostrare all'utente solo ciò che l'utente è autorizzato a conoscere (alcuni dati sono nascosti all'utente solo perché)

La mia idea iniziale era che avendo un oggetto dati posso creare da esso un oggetto dominio, quindi creare un oggetto vista da quello e poi servirlo all'utente. Comunque ora sto pensando di costruire l'oggetto vista direttamente dall'oggetto dati.

Se l'utente interroga solo alcune informazioni, recupero i dati dal database, ottengo una bella presentazione e li servo all'utente. Non toccare affatto il livello del dominio.
Se l'utente esegue un'azione, recupero i dati, ne compro i modelli, eseguo l'interazione con l'oggetto magico, li salvi tutti nel livello dati, quindi li avvolgo in presentazione e li servo.

Quanto pessima è una tale progettazione?

Purtroppo non sono esperto di terminologia di architettura / design del software, quindi potrei non riuscire a trovare la risposta solo perché non so come denominare le cose.

Modifica: non intendo scartare completamente la parte del modello. Voglio solo dire che avrò il Modello seduto su Dati e Vista seduto su Dati.

design-patterns data presentation

posta aragaer 23.03.2014 - 21:12

fonte

3 risposte

Leggi altre domande sui tag design-patterns data presentation

In che modo differisce la previsione del target del ramo dalla previsione di branca? JavaScript: raggruppa un polyfill obbligatorio ma comune nella mia libreria?

score 4 · Answer 1

Se salti il livello aziendale o di dominio, il problema è che dovrai mettere da parte la tua logica aziendale e probabilmente finirà nel tuo livello di interfaccia utente e di dati, il che renderà la tua applicazione sempre più difficile da mantenere. L'altro problema è che il tuo interfaccia utente e il livello dati dovranno probabilmente essere sostituiti, ad esempio quando vuoi passare a wpf da winforms o da SQL a EF. Quindi, anche se potrebbe richiedere un po 'più di tempo, crea il tuo business in un secondo momento, con test di unità adeguati.

score 2 · Answer 2

Prova a lavorare per un po 'con un framework MVC come ASP.NET MVC o Ruby on Rails.

In queste strutture, la maggior parte delle decisioni architettoniche vengono prese per convenzione. Quindi costruirai una semplice applicazione su un terreno ben battuto. Dopo un po ', inizierai a capire che la maggior parte dell'architettura non è poi così difficile da comprendere e sostanzialmente si riduce a tre semplici principi:

Organizzazione,
Disaccoppiamento e
Separazione delle preoccupazioni.

In MVC, la vista ha una sola funzione: mostrare qualcosa all'utente. Viene disaccoppiato dal modello tramite oggetti denominati ViewModels, che acquisiscono i dati dal modello e li trasformano nella "forma" necessaria alla vista per consentire alla vista di visualizzarli correttamente. Il Controller e il motore di routing formano collettivamente una commutazione, richieste di smistamento dal browser Web a un metodo appropriato per l'esecuzione.

Il modello contiene tutto il resto; i tuoi dati e tutta la tua logica aziendale. Puoi complicare tutto ciò che ti piace, ma il modo più tipico è creare un livello di servizio o un repository. Un lato del repository è il tuo livello dati, dall'altra i tuoi controller.

Dopo un po 'di tempo, inizi a capire che MVC è in realtà solo una metafora dell'interfaccia utente e alcuni endpoint che sposano i tuoi URL con la funzionalità dell'applicazione. Il tuo modello e livello di servizio, se progettato correttamente, può vivere tranquillamente altrettanto facilmente in un'applicazione Winforms o in un'applicazione mobile, quindi deve essere scritto una volta sola.

score 0 · Answer 3

Dovresti avere un modello, che incapsula le tue logiche di business e forse un Viewmodel, se i dati che stai presentando sono molto diversi dal tuo modello. Il punto è, cercando di evitare qualsiasi logica di business nel tuo livello di vista, e renderlo davvero fittizio. In questo modo, l'app è facile da testare (l'interfaccia utente è notoriamente difficile da testare).