Разработка независимо от рамки пользовательского интерфейса

Я пытаюсь организовать мой код гибким. Поэтому мое приложение сильно использует интерфейсы. В моем классе контроллера я хочу запустить предварительный просмотр веб-камеры на определенном элементе управления в представлении. Реализации ClientView и WebcamPreview полагаются друг на друга. Таким образом, существует один конкретный WebcamPreview для WinForms и один для WPF. Я закончил с 2-мя возможными способами:Разработка независимо от рамки пользовательского интерфейса

Вариант 1:

За: Непатентованные

Против: Generic деклараций пузырь до верхнего класса контроллера, и мне нужно, чтобы объявить по крайней мере 3 дженерики в нем , (Может быть, я делаю что-то не так?)

interface IClientView<TSelf> 
{ 
    TSelf SelfControl { get; } 
} 

interface IWebcamPreview<TSelf> 
{ 
    void Start(TSelf selfControl); 
}

Вариант 2:

Pros: Избегает к гораздо дженериков

Cons: Директивы; будет собирать различные сборки для WPF и WinForms

interface IClientView 
{ 
#if WPF 
    ControlBase SelfControl { get; } 
#else // WinForms 
    PictureBox SelfControl { get; } 
#endif 
} 

interface IWebcamPreview 
{ 
    // analog 
}

Так как я организую свой код для поддержки различных структур пользовательского интерфейса?

источник

2012-01-27 Matthias

Показывая свои решения, я думаю, что вы отвлеклись немного от своей первоначальной проблемы. Я * думаю * ваш дизайн 'IWebcamPreview' может быть ... немного перевернутым, из-за лучшего слова. Идеальное решение не будет полагаться на ВСЕ на элемент управления, который был прикреплен к нему - он мог бы - возможно, предоставить канал, который вы могли бы подключить к другим элементам управления, независимо от того, являются ли они WPF или Winforms ...? – perfectionist

Как пример: я использую DirectShow для предварительного просмотра (и захвата) изображения веб-камеры. DirectShow нуждается в ручке (IntPtr) элемента управления, где он должен сделать предварительный просмотр. Итак, как я должен его развязать? – Matthias

Вариант 3:

abstract class AbstractControl { } 

class WinFormsControl : AbstractControl { } 

class WpfControl : AbstractControl { } 

interface IClientView 
{ 
    AbstractControl SelfControl { get; } 
}

источник

2012-01-27 22:39:09

Мне нужно передать нестандартные элементы управления, такие как PictureBox и <что бы это ни было в WPF>. Так что это не сработает, или я что-то пропущу? – Matthias

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

Таким образом, 'WinFormsControl' и' WPFControl' были бы своего рода контейнером (?) Для исходных элементов управления? – Matthias

Вариант 1 является путь. Вариант 2 очень быстро будет работать с директивами. Если в один прекрасный день вы обнаружите, что помимо WPF и Winform для Windows Phone и веб-приложения вам придется коснуться большого количества кода, чтобы добавить новые директивы #elif. Код не будет слишком приятным, чтобы посмотреть на этот момент. С вариантом 1 и некоторыми хорошими организациями, то есть WPF переходит в 1 сборку, другой Winform, будущее дополнение, например, для Windows Phone, может не потребовать даже перекомпиляции существующего кода. Если это так, возможно, очень минимально.

источник

2012-01-27 22:41:59

Итак, вы утверждаете, что неизбежно иметь много дженериков, поднимающих линию? – Matthias

Разработка независимо от рамки пользовательского интерфейса

ответ

Смежные вопросы