Possiamo semplificare l'aggiunta di flussi di dati tra parti distanti di una base di codice di grandi dimensioni?

10

Quando apporto modifiche a sistemi di grandi dimensioni, spesso devo affrontare il problema che alcune funzionalità richiedono di ottenere alcuni dati da un altro pezzo, ma si trovano in parti diverse di un albero delle chiamate profondo e ramificato, che può scorrere attraverso gli ascoltatori di eventi, chiamate differite, ecc. In questo modo un semplice cambiamento può mongolfiera rapidamente.

Una citazione correlata dal post del blog di Yossi Kreinin all'indirizzo link :

You have some kind of data structure that you pass around a lot. Soon, the most valuable thing about the structure isn't the data it keeps, but the fact that it's available all the way through some hairy flow of control.

Le variabili globali sono un modo classico per far "gridare" il codice al codice distante, ma sono noti per essere problematici. Le variabili con ambito dinamico sono più limitate, ma sono anche problematiche.

Esiste qualche ricerca sul linguaggio di programmazione per risolvere questo problema? Possiamo semplificare l'aggiunta di flussi di dati inattesi a una base di codice di grandi dimensioni, pur avendo un controllo statico, test di unità semplici e altre chicche?

    
posta Vladimir Slepnev 26.02.2013 - 17:10
fonte

3 risposte

1

Si fa riferimento a CDI (Context Dependency Injection) AKA IoC (Inversion of Control). Java JSF e Spring Framework sono alcuni esempi. ASP.NET MVC ha plugin come Unity. Javascript sta iniziando ad avere strutture organizzate usando librerie come RequireJS, che ha un comportamento di iniezione visto in molti moderni framework JS. Questo è per il cablaggio di applicazioni locali e remote.

Per un accoppiamento lento tra le reti, le aziende preferiscono utilizzare i servizi Web con SOAP, REST, AJAX o chiamate di metodi remoti regolari con RPC. In Java è possibile utilizzare JAX-WS o .NET WCF per creare servizi distribuiti. Quindi li allinei in un bus di servizio o "flusso di dati" da qualsiasi lingua o piattaforma come client. Ruby, Python, Scala, Java, C #, ... qualsiasi cosa.

L'accoppiamento lento consente di suddividere e superare i problemi e i servizi sono spesso il punto di ingresso a un database per estrarre i dati. Accelerando la scala abbiamo la bestia chiamata Message Queue. Quella strada porta a quadri di tipo enterprise e infrastruttura.

Se il tuo progetto non si basa su nessuna rete, tuttavia, ci sono linguaggi come Scala, Akka, NodeJS ecc. progettati per un flusso elevato di dati all'interno di una singola applicazione. Lavorano anche con alcune o tutte le tecnologie menzionate in precedenza per progetti complessi. Ad esempio, Scala può essere utilizzato con i servizi REST JAX-RS per estrarre una sorta di "dati globali" da un'origine dati e disporre di Spring per il cablaggio interno IoC. Esistono inoltre numerosi framework di esecuzione aziendale o del flusso di lavoro in strumenti JBoss, .NET e GUI come MuleESB. In fase di sviluppo, Eclipse e Netbeans consentono di trascinare i servizi in una schermata del diagramma di flusso visivo.

Infine, Java ha ancora i fagioli Singleton. Per regolare i metodi in fase di esecuzione, utilizzare i framework proxy o reflection. Ma onestamente, è così il 1999.

Se stai facendo tante chiamate per inviare a un utente un messaggio basato sul loro fuso orario, a mio parere, c'è probabilmente un modo in due passaggi per ottenere lo stesso effetto che l'utente vede. Ma sì, i quadri CDI sono indossati dalle lingue esistenti come un cappotto che dà loro tutti i poteri flessibili che hai citato. Mi piace definirlo subconscio del mio programma, occupandomi perfettamente del lavoro sporco.

    
risposta data 02.03.2013 - 20:54
fonte
0

Il modo più semplice per farlo su larga scala è infatti utilizzare una sorta di API di incapsulamento dei dati. Potrebbe trattarsi di un archivio NoSQL o potrebbe essere un RDBMS incapsulato (o potrebbe infatti essere sia in momenti diversi che in luoghi diversi nella stessa applicazione) non c'è alcun motivo per cui non si possa avere un RDBMS che maneggi a lungo termine archiviazione e un db NoSQL che gestisce il controllo dello stato a breve termine). Potrebbe anche essere una serie di oggetti singleton.

Le tue strutture di dati possono quindi essere rese disponibili in una sorta di spazio neutrale, in un modo un po 'gestito. Questo è l'approccio che prendiamo con LedgerSMB (ma con alcune variabili semi-globali per ciò che sono essenzialmente singleti nascosti, ma ancora una volta questi sono gestiti, abbiamo scelto direttamente la memorizzazione dell'oggetto perché ha reso la gestione delle variabili un po 'più semplice ma poi ci sono tutti e 4 di loro).

Naturalmente qualsiasi approccio ha dei compromessi e non puoi aggirare quei compromessi. La chiave è guardare quali sono i compromessi (gestione vs performance vs pulizia del codice rispetto a potenziali errori di codifica) e prendere una decisione basata su ciò che è meglio per la tua applicazione.

    
risposta data 28.02.2013 - 05:12
fonte
-1

Se si utilizzano (o citano) le parole

hairy flow of control

quindi presumo che il tuo codice sia davvero un casino. Dovresti lasciarlo immediatamente. Se si utilizza la modularizzazione / separazione delle preoccupazioni, non esiste un "flusso peloso di controllo". Il tuo codice semplicemente manca di semplicità, che è anche deducibile dal fatto che tu abbia fatto riferimento a variabili globali: -).

    
risposta data 02.03.2013 - 23:40
fonte

Leggi altre domande sui tag