Qual è l'approccio migliore sia alla modularità che all'indipendenza della piattaforma?

Question

Spero che questa domanda non risulti così ampia come potrebbe sembrare a prima vista.Sto progettando un'applicazione software nel mio <sarcasm>voluminoso</sarcasm> tempo libero.Vorrei che fosse sia multipiattaforma che modulare.A questo punto, poiché sono ancora in fase di pianificazione, posso scegliere praticamente qualsiasi linguaggio e set di strumenti.

Ciò rende le cose più difficili, non più facili, perché apparentemente ci sono tanti modi per raggiungere entrambi gli obiettivi (modularità, agnosticismo della piattaforma).

La mia premessa di base è che la sicurezza, l'archiviazione dei dati, l'interazione con il sistema operativo e la configurazione dovrebbero essere tutte gestite da un'applicazione "contenitore", ma la maggior parte delle altre funzionalità verranno fornite tramite moduli plug-in.Se dovessi descriverlo ad alto livello (senza svelare completamente la mia idea), sarebbe un'unica applicazione in grado di svolgere tanti lavori diversi, tutti dedicati allo stesso obiettivo (ci sono molte cose disparate da fare, ma tutte i dati devono interagire ed essere altamente disponibili).

Questa non è un'idea nuova e non particolarmente esotica.Eppure mi ritrovo a lottare non tanto su come farlo (mi vengono in mente molti modi), ma su quale sia il metodo migliore.

Ad esempio, so che Eclipse incarna praticamente ciò che sto descrivendo, ma trovo che le applicazioni Java in generale (ed Eclipse non fa eccezione) siano troppo grandi e lente per ciò di cui ho bisogno.Idem per le app desktop scritte in Python e Ruby (che sono linguaggi eccellenti!)

Non mi dispiace ricompilare la base di codice per piattaforme diverse come eseguibili nativi.Tuttavia, C e C++ hanno i loro problemi.

Come sviluppatore C#, ho una preferenza per il codice gestito.Ma non sono ancora affatto convinto di Mono (potrei esserne convinto).

Qualcuno ha idee/esperienze/framework preferiti specifici da condividere?

Answer 1

Solo per citare un esempio:per le app .NET sono disponibili il CAB (Composite Application Block) e la Composite Application Guidance per WPF.Entrambi sono principalmente implementazioni di una serie di diversi modelli di progettazione incentrati sulla modularità e sull'accoppiamento libero tra componenti simili a un'architettura plug-in:hai un framework IOC, classi base MVC, un broker di eventi liberamente accoppiati, caricamento dinamico di moduli e altre cose.

Quindi suppongo che quel tipo di infrastruttura di pattern sia ciò che stai cercando di trovare, ma non specificamente per .NET.Ma se consideri il CAB come un insieme di implementazioni di pattern, puoi vedere che quasi ogni linguaggio e piattaforma ha una qualche forma di framework già integrato o di terze parti per i singoli pattern.

Quindi la mia opinione sarebbe:

1. Studia (se non hai familiarità con) alcuni di questi modelli di progettazione.Potresti prendere come esempio il framework CAB per la documentazione WPF: Modelli nella libreria di applicazioni composite
2. Progetta la tua architettura pensando a quale di questi modelli ritieni possa essere utile per ciò che desideri ottenere prima senza pensare a implementazioni o prodotti di modelli specifici.
3. Una volta definiti in modo più specifico i tuoi "requisiti architetturali", cerca i singoli framework che aiutano a realizzare ciascuno di questi modelli/caratteristiche per il linguaggio che decidi di utilizzare e crea il tuo framework applicativo basato su di essi.

Sono d'accordo che la parte difficile è rendere tutta questa piattaforma indipendente.Non riesco davvero a pensare a nessun'altra soluzione per scegliere un linguaggio maturo e indipendente dalla piattaforma come Java.

Answer 2

Stai progettando un'applicazione desktop o web?

Tutti qui intorno sembrano pensare che il Mono sia fantastico, ma io ancora non penso che sia pronto per l'uso nell'industria, equiparare il Mono a dove si trova il vino, ottima idea;quando funziona funziona bene, e quando non funziona... beh sei sfortunato.mod_mono per Apache è estremamente difettoso ed è difficile farlo funzionare correttamente.

Se punti al desktop, niente batte il framework Eclipse RCP (Rich Client Platform): http://wiki.eclipse.org/index.php/Rich_Client_Platform.

Puoi creare Windows, Linux e Mac con lo stesso codice e tutti i componenti dell'interfaccia utente sono nativi del sistema operativo.E RCP vince senza dubbio in termini di modularità, ha un'architettura plug-in che non ha rivali (da quello che ho visto)

Lavoro con RCP da un anno e mezzo e non so cos'altro potrebbe sostituirlo, è il numero 1 nella sua nicchia.

Se sei totalmente contrario a Java, esaminerei wxWidgets con Python o C++

Answer 3

Se desideri l'indipendenza dalla piattaforma, dovrai trovare un compromesso tra prestazioni e impegno di sviluppo.C++ potrebbe essere più veloce di Java (questo è discutibile FWIW) ma otterrai l'indipendenza dalla piattaforma molto più facilmente con Java.Python e Ruby sono sulla stessa barca.

Dubito che .NET sarebbe molto più veloce di Java (dopo tutto sono entrambi linguaggi VM), ma il grosso problema con .NET è l'indipendenza dalla piattaforma.Mono ha un obiettivo nobile e risultati sorprendentemente buoni finora, ma lo farà Sempre mettersi al passo con Microsoft su Windows.Potresti essere in grado di accettarne i limiti, ma non è comunque la stessa cosa che avere ambienti multipiattaforma identici a quelli di Java, Python e Ruby.Anche:gli strumenti di sviluppo e supporto .NET sono fortemente sbilanciati verso Windows, e probabilmente lo saranno sempre.

IMO, la soluzione migliore è prendere di mira Java...o, per lo meno, la JVM.Se non ti piace il linguaggio Java (e come sviluppatore C# immagino che non sia così) allora hai almeno opzioni come Jython, JRuby e Scala.Con JVM ottieni un'ottima indipendenza dalla piattaforma, buone prestazioni e accesso a un numero enorme di librerie e strumenti di supporto.C'è quasi sempre una libreria, una porta o un'implementazione Java che farà ciò di cui hai bisogno.Non penso che nessun'altra piattaforma abbia lo stesso numero di opzioni;c'è un valore reale in quella flessibilità.

Per quanto riguarda la modularità:dipende più dal modo in cui costruisci il software che dalla piattaforma che usi.Non so molto delle architetture dei plugin come descrivi, ma immagino che sarà possibile praticamente in qualsiasi piattaforma moderna tu scelga.

Answer 4

Se hai intenzione di sviluppare Python, puoi sempre utilizzare pirex per ottimizzare alcune delle parti più lente.

Answer 5

Con la mia limitata esperienza con Mono posso dire di esserne abbastanza convinto.Il fatto che ci sia uno sviluppo attivo e molti sforzi continui per aggiornarlo alle specifiche delle più recenti tecnologie .Net è incoraggiante.È incredibilmente utile poter utilizzare le competenze .Net esistenti su più piattaforme.Ho avuto problemi simili con le prestazioni durante il tentativo di eseguire alcune attività di base in Python + PyGTK: forse possono essere eseguite nelle mani giuste, ma è bello non doversi preoccupare delle prestazioni il 90% delle volte.

Answer 6

Per le applicazioni desktop, scriverlo in un linguaggio interpretato e utilizzare un toolkit UI multipiattaforma come wxWidgets ti porterà molto lontano verso l'indipendenza dalla piattaforma (devi solo stare attento a non utilizzare altri moduli che non siano multipiattaforma , usa cose come quelle di Python os.path module, invece di fare cose come config_path = "/home/$USER")

Detto questo, per fare a Bene applicazione multipiattaforma, dovrai fare alcune cose in modo diverso su ciascuna piattaforma.

Ad esempio, OS X è probabilmente il più diverso: le preferenze sono solitamente archiviate in ~/Library/Prefernces/ come .plists, le interfacce utente sono generalmente basate su finestre mobili, con un'unica barra dei menu ancorata nella parte superiore dello schermo.

Suppongo che sia qui che entra in gioco la modularità..Con l'esempio delle preferenze sopra, potresti tenere una lezione UserConfig, di cui disponi di versioni specifiche del sistema operativo.Quello di Windows memorizza i dati di configurazione nel file appropriato Application Data cartella o il registro.Il sistema operativo Mac utilizza file .plist su ~/Library/Preferences/, e quello unix'y usa ~/.dotfiles.