Где разместить компоненты области применения в Winforms?

2

Где вы храните компоненты, охваченные приложениями, в ваших приложениях winforms? Я вижу, что я могу создать потомок компонента в моем приложении. Затем я мог перетащить компоненты, которые хочу разделить между формами моего проекта. Является ли это лучшей практикой для совместного доступа к компонентам (невизуальные средства управления)? В Delphi у нас был DataModule. DataModule был простой конструкционной поверхностью, которая функционировала как контейнер для невизуальных компонентов. Я бы перетащил объекты Data Access на эту поверхность и получил доступ к ним из всех форм. Это обеспечило хорошее центральное расположение и кеш для моих объектов данных.

Как вы, ребята, делаете это в Winforms?

  • 0
    Вы имеете в виду глобально доступный контролируемый экземпляр компонента. Если это так, то инверсия управления МОК может вас заинтересовать. Пример реализации IOC был сделан Microsoft под названием Unity.
  • 0
    @REA_ANDREW, да, я имею в виду глобально доступный экземпляр элемента управления. У меня есть дополнительное требование, чтобы экземпляр был контейнером с поверхностью дизайна. Я смотрел на Unity для других целей, но в этом случае я хочу перетаскивать компоненты из панели инструментов VS на экземпляр.
Теги:
scope
winforms
components

3 ответа

3
Лучший ответ

System.ComponentModel.Component предоставляет конструктивную поверхность для не- визуальные компоненты в Visual Studio. Обычно в вашем проекте вы можете просто "добавить" "Компонент" и начать добавлять и настраивать невизуальные компоненты, как вы можете, с дизайнерами для форм и пользовательских элементов управления.

Для глобального доступа (область приложения) вы можете предоставить доступ к компоненту в классе Program как открытый (или внутренний) статический член.

Вы можете инициализировать этот элемент в методе Main или произвольно сложным взаимодействием между Program и MainForm или другими компонентами, например. используя инфраструктуру обслуживания, предусмотренную связанными классами в System.ComponentModel и индивидуальную реализацию IContainer.

  • 0
    Это то, что я искал. Спасибо!
0

Существует множество способов создания объектов приложения и данных для приложения. Однако было бы полезно определить, какой из разделяемых "компонентов" вам нужен доступ, на самом деле просто глобальный, или некоторые из них на самом деле "контекстуальны". В некоторых случаях существует разница, возможно, тонкая, между глобальными и контекстуальными компонентами.

В случае утилиты, такой как логгер, которая наиболее полезна в качестве глобального объекта, поскольку регистрация является одной из этих надоедливых сквозных проблем. Однако во многих случаях информация специфически контекстуальна и заслуживает того, чтобы ее можно было обернуть в каком-либо объекте контекста, доступном только для кода, который фактически выполняется в этом контексте. Контекст может быть трудно идентифицировать время от времени. Если вы можете идентифицировать его, и вы можете выяснить, как инициализировать и сделать доступным контекстный объект в нужное время до нужного кода, вы должны получить лучший продукт с более упорядоченным кодом, чем если бы вы просто создали связку доступных во всем мире.

Я рекомендую изучить BDD, Behavior Driven Development, методологию, которая сочетает гибкие и TDD-методы с более строгой методологией разработки, где контекст играет критическую роль.

0

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

Возможно, я неправильно понял ваш вопрос.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню