C# простое Событие, Повышающее - использование “отправителя” по сравнению с пользовательским EventArgs
image, который вы получаете из ImagePicker.pickImage, относится к типу File, и если вам нужно напечатать путь, вы делаете это следующим образом:
var image = await ImagePicker.pickImage(source: ImageSource.gallery);
print(image.path);
, если вам нужно загрузить изображение ищите MultipartRequest
6 ответов
Обычная схема - использовать отправителя, а не добавлять отправителя отдельно к EventArgs. Пользовательские EventArgs используются для другого состояния, например, узла дерева для события дерева, (устанавливаемого) логического значения для отменяемого события и т. Д.
Мы используем общий шаблон, поскольку он также используется классами BCL, и имеет значение для "самодельных событий" потенциально сбивает с толку. Кроме того, у нас есть глобальный шаблон издателя-подписчика IoC, но этот работает только с обычной подписью делегата EventHandler, так как типы не известны заранее. В этом случае в любом случае необходимо приведение (например, к пользовательскому EventArgs), поэтому мы могли бы с тем же успехом разыграть отправителя.
Я не думаю, что это излишне. Я согласен с преимуществами наличия отдельного класса FooEventArgs. Еще одно преимущество такого подхода заключается в том, что если вам нужно добавить больше информации к событию в будущем, вы можете просто добавить больше свойств в FooEventArgs и вам не нужно менять делегата.
I would say that you drop the subclass of EventArgs and use the sender property to identify the sender of the event. I think that the argument for following convention has merit, but the parameter in the EventArgs is not necessary. I personally would drop it and just use the sender property.
If you want to pass it as a strong type, you could also just create a custom delegate to use for your event...
public delegate void LoadedHandler(FooEventArgs args);
that way you could have it as a strong type... reusing delegates is great, but if they don't fit what you are trying to do you shouldn't feel constrained to only use the built in ones.
Что касается рекомендуемых практик, я довольно часто видел, как null поставлялся в качестве отправителя в Windows Workflow Foundation. В идеале ваши подписчики должны не обращать внимания на объект, который вызывает события.
Поэтому, если вам нужно передать объект вызывающего объекта целиком обработчикам, вам нужно будет поместить его в объект, полученный из EventArgs. С другой стороны, я предпочитаю явно передавать биты и кусочки состояния сборщика / вызывающего события вместо всего этого.
Ну, иногда проще думать о dotNET 1.1, где
Control.Invoke()
используется так же часто, как
int i;
Я бы сказал, что конвенция очень важна для этого. Есть меньше, чтобы поддерживать в долгосрочной перспективе - особенно. если ты найдешь новых людей.
Я полагаю, что это в какой-то степени предпочтение, но в моем случае, когда я прочитаю , потребителям нужно будет знать, какой объект foo вызвал событие. Я сразу подумал, что вы можете получить объект, который вызвал событие, из аргумента отправителя, так в чем же проблема?
У вашей команды есть несколько правильных точек (наличие строго типизированного свойства), но я бы сказал, что работа с руководящими принципами платформы вместо того, чтобы изобретать свое собственное, было бы лучшим решением в долгосрочной перспективе.