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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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