Объявление презентаторов и представлений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается производительности, вам придется провести сотни НКУ, прежде чем вы это заметите. Помните, что вам не обязательно иметь сборку для каждого экрана. Просто сгруппируйте их логически в несколько сборок, и все готово.