Лучшая практика для передачи информации между windows.forms

Question

Что вы делаете для передачи информации между формами? Вперед - прямое (извините) использование свойств или параметров в методе New () или DoStuff (), но как насчет отправки чего-либо назад , когда пользователь завершил работу со второй формой ? (IE. ID выбранного элемента) Мы использовали все это:

• Передал вызывающую форму в вызываемую форму как ref , чтобы вызываемая форма могла получить доступ к свойствам или методам в вызывающей форме. Мне действительно не нравится это, потому что эти две формы очень зависят друг от друга. Передача формы вызова как объекта только немного улучшает это.
• Использовать события Это несколько разъединяет код, но подписи должны совпадать в обработчике событий.
• Использование публичного интерфейса Я говорю о .NET, встроенном в него, но я полагаю, вы могли бы создать свой собственный. Это кажется мне лучшим.

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

Answer 1

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

Если у вас нет доменных сущностей, таких как Сотрудник, Учетная запись, Местоположение и т. Д., Вы обнаружите, что пишете формы со множеством свойств и создаете тонны неуклюжих зависимостей. Со временем это может быть очень грязно.

Как только у вас будет доменная сущность, с вами будет намного легче иметь дело. Например, чтобы отредактировать сотрудника с помощью формы, вы можете просто создать свойство сотрудника, например:

NewForm myForm = new NewForm();             
myForm.Employee = employeeToEdit; // This can have state 
myForm.ShowDialog(); 
Employee editedEmployee= myform.Employee;

EmployeeFacade.SaveEmployee(editedEmployee); // Or whatever

Что касается событий, для приложений Winform / WPF почти всегда полезно создать глобальный EventManager, использующий шаблон публикации / подписки для обработки связи между формами. Очень редко у меня когда-либо будет одна форма «говорить» непосредственно с любой другой формой. Это еще одна тема, поэтому я не буду вдаваться в подробности, если вам нужны примеры, я могу привести несколько, которые я сделал.

Райфорд Брукшир

Answer 2

Создайте открытые свойства для формы, затем дождитесь закрытия формы и проверьте свойства, прежде чем утилизировать новую форму.

NewForm myForm = new NewForm();
myForm.ShowDialog();
string x = myform.MyProperty;

Answer 3

this.Hide (); строка [] имя = новая строка []; new frmFormName = new frm (строка «что», «строка», «строка идет», «строка в», «строка вставлена», «вставка»); this.ShowDialog (); this.Show ();

Answer 4

Одна вещь, которую я добился успеха, - это создание в приложении облегченной системы обработки событий публикации / подписки. Это было в .net 1.1, и я не уверен, как это изменится с генериками. По сути, у нас был синглтон, который содержал хеш-таблицу со строковым ключом и многоадресные delgates.

Синглтон имел такие методы, как RegisterForEvent (строковый ключ, обработчик делегата), RaiseEvent (ключ, данные) и т. Д. *

Затем мы определили стандартный делегат и сказали, что все пользователи должны реализовать этот шаблон, например, наши обработчики должны быть: метод void (отправитель объекта, аргументы CustomEventArgs). Издатели будут определять свой собственный производный класс CustomEventArgs.

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

У нас были так называемые разные подсистемы, например, у нас была подсистема, которая контролировала интернет-соединение, и когда оно вызывало событие, пользовательский интерфейс менялся, указывая состояние их соединения, у нас также была служба очередей, которая отправляла сообщения сервер, когда он увидел, что соединение оборвалось, мы прекратили публиковать.

Недостатком является то, что он очень слаб, по крайней мере, наша реализация была, но есть способы улучшить это.

Answer 5

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

Я не уверен, насколько сложнее вы хотите, чтобы это получилось. В прошлом я использовал статический одноэлементный объект для хранения состояния приложения. Объект app-state предоставит обработчики событий, которые могут прослушивать другие части программы. Основная форма создаст состояние приложения (просто получит ссылку на него) и прослушает определенные события в нем. Тогда основная форма создаст дочерние формы и элементы управления для выполнения работы. Потомки будут изменять свойства объекта app-state, что, в свою очередь, будет запускать события, которые будет прослушивать основная форма. Таким образом, различные формы и элементы управления были отделены друг от друга. Недостатком является то, что они были тесно связаны с синглтоном состояния приложения.

Answer 6

Хотите получить доступ к элементам пользовательского интерфейса второй формы? Я думаю, что более чистый способ заключается в использовании общего объекта для передачи данных обратно в форму вызова. Передайте объект в качестве параметра второму конструктору формы, который может заполнить поля экземпляра и вернуть этот экземпляр в вызывающую форму. Этот объект также может вызывать любые события (например, события изменения свойства), чтобы уведомить вызывающую форму (или подписчиков), если требуется.