Где вы храните компоненты, охваченные приложениями, в ваших приложениях winforms? Я вижу, что я могу создать потомок компонента в моем приложении. Затем я мог перетащить компоненты, которые хочу разделить между формами моего проекта. Является ли это лучшей практикой для совместного доступа к компонентам (невизуальные средства управления)? В Delphi у нас был DataModule. DataModule был простой конструкционной поверхностью, которая функционировала как контейнер для невизуальных компонентов. Я бы перетащил объекты Data Access на эту поверхность и получил доступ к ним из всех форм. Это обеспечило хорошее центральное расположение и кеш для моих объектов данных.
Как вы, ребята, делаете это в Winforms?
System.ComponentModel.Component предоставляет конструктивную поверхность для не- визуальные компоненты в Visual Studio. Обычно в вашем проекте вы можете просто "добавить" "Компонент" и начать добавлять и настраивать невизуальные компоненты, как вы можете, с дизайнерами для форм и пользовательских элементов управления.
Для глобального доступа (область приложения) вы можете предоставить доступ к компоненту в классе Program как открытый (или внутренний) статический член.
Вы можете инициализировать этот элемент в методе Main или произвольно сложным взаимодействием между Program и MainForm или другими компонентами, например. используя инфраструктуру обслуживания, предусмотренную связанными классами в System.ComponentModel и индивидуальную реализацию IContainer.
Существует множество способов создания объектов приложения и данных для приложения. Однако было бы полезно определить, какой из разделяемых "компонентов" вам нужен доступ, на самом деле просто глобальный, или некоторые из них на самом деле "контекстуальны". В некоторых случаях существует разница, возможно, тонкая, между глобальными и контекстуальными компонентами.
В случае утилиты, такой как логгер, которая наиболее полезна в качестве глобального объекта, поскольку регистрация является одной из этих надоедливых сквозных проблем. Однако во многих случаях информация специфически контекстуальна и заслуживает того, чтобы ее можно было обернуть в каком-либо объекте контекста, доступном только для кода, который фактически выполняется в этом контексте. Контекст может быть трудно идентифицировать время от времени. Если вы можете идентифицировать его, и вы можете выяснить, как инициализировать и сделать доступным контекстный объект в нужное время до нужного кода, вы должны получить лучший продукт с более упорядоченным кодом, чем если бы вы просто создали связку доступных во всем мире.
Я рекомендую изучить BDD, Behavior Driven Development, методологию, которая сочетает гибкие и TDD-методы с более строгой методологией разработки, где контекст играет критическую роль.
Обычно я использую singleton для таких вещей, как классы журналов, адаптеры баз данных и т.д. Это удобно, если вы хотите статическую ссылку на свои объекты во всем приложении.
Возможно, я неправильно понял ваш вопрос.