Модульность приложения C# Compact Framework 2.0

Question

В настоящее время мы разрабатываем новое портативное программное обеспечение.Я не могу обсуждать суть приложения, поэтому вместо этого приведу пример.

Мы разрабатываем портативное программное обеспечение для управления школой.Мы хотим сделать каждый аспект системы модульным, чтобы разные школы могли использовать разные функции.

Наша система запустится с главного меню и экрана входа в систему.Я бы хотел, чтобы это было основой системы и туда, куда будут добавляться модули.Т.е.У меня будет проект под названием SchoolPda.

Затем я хочу иметь разные модули.То есть мне нужен модуль регистрации, который будет обрабатывать регистрацию студентов.Мне нужен классный модуль для управления чистотой класса и т. д.

Я бы мог видеть, как это работает, включая/не включая различные библиотеки DLL, а также наличие в главном меню базовой системы кнопок для доступа к этим модулям, если библиотеки DLL существуют.Это именно то, что нам нужно.

Есть ли у кого-нибудь опыт сделать что-то подобное?Как лучше всего это сделать?Нам не нужно беспокоиться о базе данных, поскольку она всегда будет полной базой данных, но аспекты не будут заполняться, если связанные модули не существуют.

Answer 1

Я участвовал в проектах, в которых это делалось двумя способами:

• В одном проекте мы не развертывали определенные библиотеки DLL, если у клиентов не было лицензий.Это то, что вы предлагаете.Все работало нормально.Конечно, не было возможности включить эти модули без дополнительной установки, но для этого приложения это имело смысл.

• В другом проекте мы развернули все и предоставили конечным пользователям только меню, кнопки и т. д.на которую у клиента была лицензия.Мы сделали это, потому что тогда пользователь мог легко добавить дополнительный модуль, добавив для него лицензию.Когда лицензия была добавлена, она волшебным образом появилась при следующем входе в систему.

Итак, по моему опыту, я бы посоветовал рассматривать вашу модель лицензирования как одну важную часть вашего решения.Подумайте, захотите ли вы когда-нибудь добавлять эти дополнительные модули «на лету».

Answer 2

В настоящее время я также разрабатываю приложение, которое работает как на компактной, так и на полной платформе и построено модульно.

Я реализовал этот способ так, что он сканирует местоположение для DLL и перечисляет все типы и проверяет, есть ли у них «ScreenInfoAttribute». или " WidgetInfoAttribute " определен, который содержит полезную информацию о классе.

вот фрагмент кода, он содержит код 3.5, но это потому, что мы недавно переключились с 2.0, но принцип работает в 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

Я не знаю, будет ли это работать в CLR, но посмотрите МЭФ, для создания способа обнаружения и загрузки ваших DLL/модулей.Вы также можете иметь в своих модулях метод GetMenuItem (или что-то в этом роде), который получает необходимую информацию, чтобы в вашем главном меню можно было добавить кнопку.

Очевидно, используйте другой дизайн для вашего главного меню, если это имеет смысл, но вы хотите, чтобы оно действительно было одновременно модульным и расширяемым, чтобы вы могли писать свое ядро ​​и в будущем продолжать писать новые компоненты без необходимости изменить свое ядро.

Извините, если это не имеет большого смысла.Просто надеялся дать вам идею в одном направлении.

Answer 4

Просто позвольте каждому модулю реализовать общий интерфейс. Добавьте методы, такие как GetButtons () или GetActions ().

Затем вы можете поместить информацию о AssemblyName и ClassName в файл конфигурации. Теперь легко загрузить указанную сборку и создать экземпляр класса с помощью Activator.CreateInstance, привести его к своему интерфейсу и вызвать методы GetButtons () и т. Д.