Modularizzazione di un'applicazione C # Compact Framework 2.0

Question

Attualmente stiamo sviluppando un nuovo software portatile. Non posso discutere la natura dell'applicazione, quindi userò un esempio.

Stiamo progettando software portatili per la gestione di una scuola. Vogliamo modulare ogni aspetto del sistema in modo che scuole diverse possano utilizzare funzionalità diverse.

Il nostro sistema inizierà con un menu principale e una schermata di accesso. Vorrei che questa fosse la base del sistema e dove i moduli verranno aggiunti. Cioè Avrò un progetto chiamato SchoolPda.

Voglio quindi avere diversi moduli. Ad esempio, desidero un modulo di registrazione che gestirà le registrazioni degli studenti. Voglio un modulo di classe per gestire la pulizia della classe, ecc.

Il modo in cui probabilmente vedrei questo lavoro è includere / non includere diverse DLL e avere il menu principale del sistema di base espone i pulsanti per accedere a quei moduli se esistono le DLL. Questo è proprio il tipo di cosa che stiamo cercando.

Qualcuno ha esperienza nel fare qualcosa del genere? Quale sarebbe il modo migliore per farlo? Non dobbiamo preoccuparci del database poiché il database sarà sempre il database completo, ma gli aspetti non verranno popolati se i moduli associati non esistono.

Answer 1

Ho partecipato a progetti che l'hanno fatto in due modi:

• In un progetto non abbiamo distribuito determinate DLL se i clienti non avevano la licenza. Questo è quello che stai suggerendo. Ha funzionato bene. Ovviamente, non c'era modo di abilitare quei moduli senza un'installazione aggiuntiva, ma aveva perfettamente senso per quell'app.

• In un altro progetto abbiamo distribuito tutto ed esposto solo agli utenti finali i menu, i pulsanti, ecc. per i quali il cliente era autorizzato. Lo abbiamo fatto perché in questo modo l'utente potrebbe facilmente aggiungere un modulo aggiuntivo aggiungendo una licenza per esso. Quando è stata aggiunta la licenza, la roba è stata mostrata magicamente al prossimo accesso.

Quindi, nella mia esperienza, direi che considera il tuo modello di licenza come un grande pezzo della tua decisione. Pensa se vorresti mai aggiungere quei moduli extra al volo.

Answer 2

Attualmente sto anche sviluppando un'applicazione che funziona sia su framework Compact che Full ed è costruita modulare.

Il modo in cui l'ho implementato è che esegue la scansione di una posizione alla ricerca di DLL e si rallegra su ogni tipo e osserva se hanno un "ScreenInfoAttribute " o " WidgetInfoAttribute " definito che contiene informazioni utili sulla classe.

ecco uno snippet, contiene il codice 3.5, ma è perché di recente abbiamo effettuato il passaggio da 2.0, ma il principio funziona in 2.0

public void Analyze(FileInfo file) {
        Assembly asm = Assembly.LoadFrom(file.FullName);
        List<Data.AnyPlugin> types = GetPluginTypes(asm.GetTypes());

        if (types.Count > 0) {
            types.ForEach(x => x.AssemblyPath = file.FullName);
            if (_plugins.ContainsKey(file.FullName)) {
                _plugins[file.FullName].Plugins.AddRange(types);
            } else {
                AssemblyPlugin asp = new AssemblyPlugin();
                asp.Ass = asm;
                asp.Plugins = types;
                _plugins.Add(file.FullName, asp);
            }
        }
    }

    private List<Data.AnyPlugin> GetPluginTypes(Type[] types) {
        List<Data.AnyPlugin> returnTypes = new List<AnyPlugin>();
        foreach (Type t in types) {
            Data.AnyPlugin st = GetPluginType(t);
            if (st != null) returnTypes.Add(st);
        }
        return returnTypes;
    }

    private Data.AnyPlugin GetPluginType(Type type) {
        if (type.IsSubclassOf(typeof(Screens.bScreen<T>))) {
            Screens.ScreenInfoAttribute s = GetScreenAttrib(type);
            if (s != null) {
                return new Data.ScreenPlugin("", type, s);
            }
        } else if (type.IsSubclassOf(typeof(Widgets.bWidget<T>))) {
            Widgets.WidgetInfoAttribute w = GetWidgetAttrib(type);
            if (w != null) return new Data.WidgetPlugin("", type, w);
        }
        return null;
    }

    private Screens.ScreenInfoAttribute GetScreenAttrib(Type t) {
        Attribute a = Attribute.GetCustomAttribute(t, typeof(Screens.ScreenInfoAttribute));
        return (Screens.ScreenInfoAttribute)a;
    }

Answer 3

Non so se funzionerà sul CLR ma dai un'occhiata a MEF , per creare un modo per scoprire e caricare dll / moduli. Potresti anche avere i tuoi moduli con un metodo GetMenuItem (o qualcosa del genere di ilk) che ottiene le informazioni richieste in modo che il tuo menu principale possa aggiungere un pulsante.

Ovviamente, usa un design diverso per il tuo menu principale se ha senso, ma vorrai che sia veramente sia modulato che estensibile, in modo da poter scrivere il tuo core e in futuro continuare a scrivere nuovi componenti, senza dover cambiare il tuo core.

Mi dispiace se questo non ha più senso. Speravo solo di darti un'idea in una direzione.

Answer 4

Lascia che ogni modulo implementi un'interfaccia comune. Aggiungi metodi come GetButtons () o GetActions ().

È quindi possibile inserire informazioni su AssemblyName e ClassName in un file di configurazione. Ora è facile caricare l'Assemblea specificata e creare un'istanza della classe con Activator.CreateInstance, lanciarla sull'interfaccia e chiamare i metodi GetButtons (), ecc.