Объявление докладчиков и просмотров

Question

Я делаю приложение WPF, которое состоит из экранов (Presenter + View). Я хочу иметь возможность объявить эти экраны в файле конфигурации или базе данных SQL. Я пытался найти хорошее решение, от которого отказался, и спрашиваю, как некоторые из вас проектируют такие вещи? Я работаю над этим более недели, и каждое решение, которое я придумываю, воняет.

В моем приложении WPF у меня есть древовидная структура, которая представляет экраны. Когда пользователь нажимает на узел, экран загружается. Я хочу иметь возможность заполнять триоды из файла конфигурации или базы данных. Программа не должна заботиться о том, где они хранятся, поэтому я могу поменять хранилище конфигурации на хранилище базы данных. Если у меня хранится информация о экране, я также могу использовать контейнер IOC, чтобы создать для меня экраны и получить их по имени. Вот пример схемы файла конфигурации, который я придумал:

<screen name="" title="" presenterType="" viewType=""/>
<screen ...>
    <screen .../>
    <screen .../>
</screen>
<screen .../>

Последнее решение, которое я придумала, - это использование ScreenService, который запрашивает ScreenRepository для объектов ScreenInfo. Тогда я смогу заполнить дерево и контейнер IOC этой информацией.

Это звучит как хорошее решение? Что бы вы сделали по-другому? И как вы проектируете такую ​​систему в своем собственном программировании?

Answer 1

Извините, я должен был упомянуть, что использую .NET 3.5. Я так привык писать на форуме ASP.NET, что забыл.

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

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

Спасибо за ответ. Мне нравится видеть, как другие делают вещи. Это помогает мне понять многие из этих концепций проектирования, так как я только начинаю путь с шаблонов проектирования (только что заказал книгу PEAA) Кто-нибудь еще, пожалуйста, поделитесь своими мыслями. Это может также помочь кому-то, как я, кто наткнулся на этот вопрос.

Answer 2

Когда вы возвращаете объекты из фабричного метода, вы также можете включить иерархию. Например, у моих фабрик форм есть два метода: один возвращает список фигур, добавленных в основной список, другой возвращает библиотеки форм. В то время как пользователь может определять и изменять фактические библиотеки, у меня есть автоматически созданный набор по умолчанию, который можно использовать для устранения неполадок и начальной установки. Это иерархическое.

Однако ShapeLibrary состоит из ShapeLibraryItem. В ShapeLibraryItem хранится ключ, позволяющий извлекать фигуру из списка мастер-программ. Таким образом, нажимается кнопка или элемент, он смотрит на элемент ShapeLibrary, с которым он связан. Получить ключ, использовать ключ для получения программы фигур, а затем использовать интерфейс пользовательского интерфейса для рисования экрана.

Если на вашем экране есть информация об иерархии, встроенная как одно из многих его свойств, тогда я рекомендую разделить ее на элемент иерархии. Затем может быть создан HierarchyList, который состоит из HierarchyLists ИЛИ HierarchyItem. Я бы сделал интерфейс IHierarchyItem, чтобы HierarchyLists выглядели как элемент.

Основным отличием является поведение. Когда вы щелкаете по списку HeirarchyList, открывается другой список (или расширяется и т. Д.), На экране появляется настоящий Предмет.

Таким образом, ваша сборка будет иметь два класса, помеченных одним из двух атрибутов. Один из них будет ScreenFactory, а другой - HierarchyFactory.

Обратите внимание, что вам не нужно использовать ключи, вы можете напрямую связать HierarchyItem с формой. Я использую ключи GUID, чтобы избежать соединения каждый раз. Сцепление не всегда плохо, но не всегда хорошо. Поскольку GUID фактически уникальны, он работает одинаково.

Что касается производительности, вам придется собрать сотни СБОРОВ, прежде чем вы заметите это. Помните, что вам не нужно иметь сборку для каждого экрана. Просто сгруппируйте их логически в несколько сборок, и все готово.

Answer 3

Как правило, вам необходимо использовать шаблон Factory для таких ситуаций. Ваш микс ScreenService, ScreenRepository и Screeninfo звучит так, как будто вы это сделали. Здесь - это базовый обзор фабричного образца. Вы можете использовать статью из Википедии в качестве отправной точки, чтобы увидеть, есть ли какие-либо варианты или аспекты, которые вы пропустили.

Я разработал и поддерживаю приложение CAD / CAM, в котором есть несколько библиотек предварительно заданных параметрических фигур, в которых пользователь может вводить несколько измерений и вычислять форму для резки. Каждая фигура имеет собственную настройку экрана. Я использую шаблон, подобный вашему, во время запуска моих приложений.

Я сканирую каталог библиотеки форм для каждой сборки, выбираю фабричный класс, у которого есть метод, который извлекает список фигур, загружаю его в основной список. Когда пользователь нажимает на кнопку панели инструментов или выбирает из списка, программное обеспечение использует клавишу, чтобы вытащить правильную фигуру из списка, которая предоставляет интерфейс IShapeScreen. Форма, которая управляет формами, использует этот интерфейс, чтобы нарисовать правильный экран ввода для этой формы.

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

Обратите внимание, что вам может не потребоваться использовать текстовый конфигурационный файл. Используя атрибуты, некоторые интерфейсы, которые вы определяете, и API отражения .NET, вы можете просто выбросить библиотеки DLL в каталог, программа может сканировать этот каталог и правильно извлекать нужные объекты. В вашем случае экранные объекты. Однако, если вы хотите, чтобы человек редактировал конфигурацию, тогда обязательно нужен текстовый файл. Я предполагаю, что вы используете .NET API, как вы отметили .NET.