Концепция UC (пользовательский компонент) в формах Win32/.NET Win

Пару лет назад я когда-то работал в компании веб-разработчиком. Это моя первая работа по веб-разработке на Sirius (ASPx/C#), так что это очень увлекательно, и я многое узнал об этом мире с точки зрения разработчика.

В этой группе у нас была концепция для страниц, загружаемых на странице UC (Пользовательские элементы управления), я не знаю, одинаково ли это во всех командах веб-разработчиков с каждым языком, я предполагаю, что это так.

Контракт закончился, и я вернулся к разработке приложения win32 «winForm».

Но с тех пор я попытался применить тот же принцип для моей разработки win32, которую я изучаю там, имея в виду набор UC (визуальные пользовательские элементы управления), которые я загружаю в форму. Это обычные визуальные компоненты, не загруженные в тулбокс, код есть в проекте, но компонент не разрабатывается в форме, они там загружены.

Я хотел бы знать мнения об этом подходе, что другие делают аналогично или лучше этого И улучшения, которые могут помочь нам ускорить разработку и увеличить повторное использование кода, потому что это то, о чем идет речь.


winforms winapi code-reuse
person Jlouro    schedule 13.02.2009    source источник
comment
Вы имеете в виду, что вы разрабатываете пользовательские элементы управления, которые затем создаются и добавляются в форму во время выполнения?   -  person ng5000    schedule 13.02.2009

Ответы (1)


arrow_upward
1
arrow_downward

Если вы используете компоненты макета в Winforms, этот может быть приемлемым подходом, хотя я думаю, что разница между веб-формами и Windows Forms (примечание: НЕ WPF!) заключается в том, что в первом вы делаете много «компоновки», поэтому концепция UserControl так полезна, тогда как в последнем вы работаете с очень сложными элементами управления (например, третьей стороной — на моем последнем концерте мы использовали невероятное управление сеткой через небольшую компанию под названием Infralution)

Основная проблема, которую я вижу, связана с макетами, поскольку модель рендеринга немного отличается от веб-модели. Я ничего не знаю о вашем приложении, но если оно "работает", это самое главное. Я предполагаю, что в этом случае вы правильно используете такие вещи, как FlowLayoutPanel и TableLayoutPanel.

Если вы хотите пойти более каноническим путем, взгляните не только на создание компонентов, но и на то, как вы можете использовать модель наследования для более надежного составления вашего приложения — имея базовый класс Form с контейнерами, в которых находится ваш тип «UserControl». компоненты идут, а затем с помощью какой-то инъекции зависимостей на основе интерфейса для их замены во время работы приложения.

Наконец, взгляните на некоторые из приложений Windows Forms с открытым исходным кодом, чтобы понять, не слишком ли вы требовательны к себе, поскольку общий пользовательский интерфейс и повторно используемые компоненты являются целью каждого приложения. Несмотря на то, что я всегда думал, что материалы Microsoft Patterns & Practices склонны к раздуванию, есть несколько хороших идей, и вам следует изучить некоторые из подходов Композитный блок приложения пользовательского интерфейса, который они выпустили.

Хорошо, не в заключение, есть еще одна вещь, которую я хотел бы добавить: внимательно посмотрите на WPF, который вернет многие концепции из ваших дней веб-разработки и даст вам такую ​​​​мощь в настольном приложении.

person t3rse    schedule 13.02.2009