Modularização uma Aplicação C # compacto Quadro 2.0

Question

Estamos actualmente a desenvolver uma nova peça de software de mão. Eu não posso discutir a natureza da aplicação, por isso vou usar um exemplo em seu lugar.

Estamos projetando software hand-held para o gerenciamento de uma escola. Queremos modularizar cada aspecto do sistema para que as escolas diferentes podem usar diferentes recursos.

O nosso sistema vai começar com um menu principal e uma tela de login. Eu gostaria que esta é a base do sistema e ser onde os módulos serão adicionados ao. Ou seja, Eu vou ter um projeto chamado SchoolPda.

Então eu quero ter diferentes módulos. Ou seja, eu quero um módulo de registro que irá lidar com inscrições de estudantes. Eu quero um módulo de sala de aula para gerenciar a limpeza da sala de aula, etc.

A maneira que eu, possivelmente, ver este trabalho está incluindo / não incluindo DLLs diferentes e ter o menu principal do sistema de base de expor botões para acessar os módulos se existirem as DLLs. Isso é apenas o tipo de coisa que estamos procurando.

Alguém tem alguma experiência em fazer algo assim? Qual seria a melhor maneira de fazê-lo? Nós não precisa se preocupar com o banco de dados como o banco de dados será sempre o banco de dados completo, mas aspectos não vai conseguir povoada se não existirem os módulos associados.

Answer 1

Eu estive em projetos que tenham feito isso de duas maneiras:

• Em um projeto que não implementar certas DLLs se os clientes não foram licenciados. Isso é o que você está sugerindo. Funcionou muito bem. Claro, não havia nenhuma maneira para permitir a esses módulos sem um adicional de instalar, mas faz todo o sentido para esse aplicativo.

• Em outro projeto, implantado tudo e só exposto aos usuários finais os menus, botões, etc. para o qual o cliente foi licenciados. Fizemos isso porque então o usuário poderia facilmente add-on um módulo adicional, adicionando uma licença para ele. Quando a licença foi adicionado, as coisas magicamente apareceu no próximo login.

Assim, em minha experiência, eu diria que olhar para o seu modelo de licenciamento como um grande pedaço de sua decisão. Pense se você jamais iria querer adicionar os módulos extra na mosca.

Answer 2

Atualmente, estou também desenvolvendo um aplicativo que roda tanto em estrutura compacta e completa e é construído modular.

A maneira que eu implementado é que ele verifica um local para dll e enummerates sobre cada tipo e aparência se eles têm um "ScreenInfoAttribute" ou "WidgetInfoAttribute" definido que contém informação útil sobre a classe.

Aqui está um trecho, ele contém 3,5 código, mas isso é porque, recentemente, fez a troca de 2,0, mas o princípio funciona em 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

Eu não sei se ele vai trabalhar no CLR, mas ter um olhar para MEF , para a criação de uma forma de descobrir e carregar suas DLLs / módulos. Você também pode ter seus módulos têm um método GetMenuItem (ou algo a tal da laia) que recebe as informações necessárias para que o seu menu principal pode adicionar um botão.

Obviamente, use um design diferente para o seu menu principal se faz sentido, mas você quer que ele seja verdadeiramente tanto modulized e extensível, de modo que você pode escrever o seu núcleo, e no futuro continuar a escrever novos componentes, sem ter que mudar você núcleo.

Me desculpe se isso não faz a maior quantidade de sentido. Só esperava para lhe dar uma ideia em uma direção.

Answer 4

Apenas deixe cada módulo implementar uma interface comum. Adicionar Métodos como GetButtons () ou getActions ().

Você pode então colocar infomation sobre a AssemblyName eo ClassName em um config - arquivo. Agora seus fácil de carregar o assembly especificado e criar uma instância da classe com Activator.CreateInstance, lançá-lo à sua interface e chamar os GetButtons (), etc. métodos.