Modularización de una aplicación C # Compact Framework 2.0

Question

Actualmente estamos desarrollando una nueva pieza de software de mano. No puedo discutir la naturaleza de la aplicación, así que usaré un ejemplo en su lugar.

Estamos diseñando software de mano para administrar una escuela. Queremos modularizar cada aspecto del sistema para que diferentes escuelas puedan usar diferentes funciones.

Nuestro sistema comenzará con un menú principal y una pantalla de inicio de sesión. Me gustaría que esta sea la base del sistema y donde se agregarán los módulos. Es decir. Tendré un proyecto llamado SchoolPda.

Entonces quiero tener diferentes módulos. Es decir, quiero un módulo de registro que maneje los registros de estudiantes. Quiero un módulo de aula para gestionar la limpieza del aula, etc.

La forma en que posiblemente vea este funcionamiento es incluir / no incluir diferentes dlls y tener el menú principal del sistema base para exponer los botones para acceder a esos módulos si existen los dlls. Ese es el tipo de cosa que buscamos.

¿Alguien tiene alguna experiencia haciendo algo como esto? ¿Cuál sería la mejor manera de hacerlo? No tenemos que preocuparnos por la base de datos, ya que la base de datos siempre será la base de datos completa, pero los aspectos no se completarán si los módulos asociados no existen.

Answer 1

He estado en proyectos que lo han hecho de dos maneras:

• En un proyecto no implementamos ciertas DLL si los clientes no tenían licencia. Eso es lo que estás sugiriendo. Funcionó bien Por supuesto, no había forma de habilitar esos módulos sin una instalación adicional, pero tenía mucho sentido para esa aplicación.

• En otro proyecto implementamos todo y solo expusimos a los usuarios finales los menús, botones, etc. para los cuales el cliente tenía licencia. Lo hicimos porque entonces el usuario podía agregar fácilmente un módulo adicional agregando una licencia para él. Cuando se agregó la licencia, las cosas aparecieron mágicamente en el próximo inicio de sesión.

Entonces, en mi experiencia, diría que mire su modelo de licencia como una gran parte de su decisión. Piense si alguna vez desearía agregar esos módulos adicionales sobre la marcha.

Answer 2

Actualmente también estoy desarrollando una aplicación que se ejecuta tanto en el marco compacto como en el completo y está construida de forma modular.

La forma en que lo implementé es que escanea una ubicación de dll y enumera cada tipo y mira si tienen un " ScreenInfoAttribute " o " WidgetInfoAttribute " definido que contiene información útil sobre la clase.

aquí hay un fragmento, contiene código 3.5, pero eso es porque recientemente hicimos el cambio de 2.0, pero el principio funciona en 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

No sé si funcionará en el CLR, pero eche un vistazo a MEF , para crear una forma de descubrir y cargar sus dlls / módulos. También puede hacer que sus módulos tengan un método GetMenuItem (o algo similar) que obtiene la información requerida para que su menú principal pueda agregar un botón.

Obviamente, use un diseño diferente para su menú principal si tiene sentido, pero querrá que sea realmente tanto modulado como extensible, para que pueda escribir su núcleo y en el futuro continuar escribiendo nuevos componentes, sin tener que cambiar tu núcleo.

Lo siento si esto no tiene la mayor cantidad de sentido. Solo esperaba darte una idea en una dirección.

Answer 4

Simplemente deje que cada módulo implemente una interfaz común. Agregue métodos como GetButtons () o GetActions ().

Luego puede colocar información sobre el AssemblyName y el ClassName en un archivo de configuración. Ahora es fácil cargar el ensamblado especificado y crear una instancia de la clase con Activator.CreateInstance, enviarlo a su interfaz y llamar a los métodos GetButtons (), etc.