Обработчики событий в XAML или Коде Позади

Я плохо знаком с Silverlight и XAML. При попытке изучить синтаксис и лучшие практики я продолжаю сталкиваться с несоответствием (или по крайней мере мне кажется что путь) в пути некоторые обработчики событий реализации.

В примере из MSDN я вижу следующий используемый код:


  
    
    
  


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

 public Window1()
        {
            InitializeComponent();

            TransformGroup group = new TransformGroup();

            ScaleTransform xform = new ScaleTransform();
            group.Children.Add(xform);

            TranslateTransform tt = new TranslateTransform();
            group.Children.Add(tt);

            image.RenderTransform = group;

            image.MouseWheel += image_MouseWheel;
            image.MouseLeftButtonDown += image_MouseLeftButtonDown;
            image.MouseLeftButtonUp += image_MouseLeftButtonUp;
            image.MouseMove += image_MouseMove;
        }

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

Существует ли лучшая практика для этой ситуации?

7
задан Community 23 May 2017 в 11:45
поделиться

3 ответа

Йонатан, твой вопрос не ясен! В зависимости от ситуации вы можете использовать много различных конструкций.

Одним из решений является наличие явных методов setup () и teardown (), которые вызываются методом run () перед вызовом runImpl (). Это позволит подклассам переносить/переопределять их по мере необходимости.

class Runner(object):
    def run(self):
        self.setup()
        self.runImpl()
        self.teardown()
    def setup(self):
        pass
    def teardown(self):
        pass

class RunnerImplementation(Runner):
    def runImpl(self):
        pass # do some stuff
    def setup(self):
        print "doing setup"
        super(RunnerImplementation, self).setup()
    def teardown(self):
        print "doing teardown"
        super(RunnerImplementation, self).teardown()

Однако вы упомянули множественное наследование, что означает, что это вовсе не то направление, которое вы должны принимать.

Ваше упоминание множественного наследования и обертывания (как в «декораторах») заставляет меня предположить, что вы хотите иметь возможность писать различные реализации «бегунка», каждая со своим собственным процессом настройки/отрыва, при повторном использовании частей настройки/отрыва между различными «бегунами».

Если это так, вы можете определить ресурсы, которые знают, как настроить и разорвать себя, и каждый из них объявит, какие ресурсы ему нужны. Метод run () запускает соответствующий код установки/разрыва каждого ресурса и делает их доступными для метода runImpl ().

class Resource(object):
    name = None # must give a name!
    def setup(self):
        pass
    def teardown(self):
        pass

class DatabaseResource(Resource):
    name = "DB"
    def setup(self):
        self.db = createDatabaseConnection()
    def teardown(self):
        self.db.close()

class TracingResource(Resource):
    name = "tracing"
    def setup(self):
        print "doing setup"
    def teardown(self):
        print "doing teardown"

class Runner(object):
    RESOURCES = []
    def run(self):
        resources = {}
        for resource_class in self.RESOURCES:
            resource = resource_class()
            resource.setup()
            resources[resource_class.name] = resource

        self.runImpl(resources)

        # teardown in opposite order of setup
        for resource in reversed(resources):
            resource.teardown()

class RunnerA(Runner):
    RESOURCES = [TracingResource, DatabaseResource]

    def runImpl(self, resources):
        resources['DB'].execute(...)
-121--4043605-

Я получил 404 не смог подключить ошибку, затем я установил wampmanager.exe для запуска как Xp Sp3 и, кажется, это работает нормально, это можно сделать


  1. Щелкните правой кнопкой мыши на нем
  2. Свойства
  3. нажмите вкладку с надписью "Совместимость"
  4. Галочка только что " Режим "
  5. Выберите Windows XP (пакет обновления 3)
  6. Нажмите кнопку" Применить ", затем OK

-121--1548338-

Если не требуется динамическое изменение обработчиков событий для объекта, я предпочитаю определить его в самом XAML.

4
ответ дан 2 September 2019 в 05:26
поделиться

При первом подходе есть два «кодовых сайта»

  1. XAML, где определяются элементы пользовательского интерфейса , а события проводятся в одном месте.
  2. Процедуры обработчика событий в коде позади

во втором существует 3 «кодовые сайты»

  1. XAML, в котором определены элементы пользовательского интерфейса
  2. конструктор, где проводятся события
  3. Процедуры обработчика в коде позади

лично я предпочитаю первый подход. Если я удалю элемент, мне нужно только найти обработчики событий, которые нужно удалить, мне не нужно также редактировать конструктор класса.

Конечно, это правило, там будет много исключений.

4
ответ дан 2 September 2019 в 05:26
поделиться

Лучшая практика: Использование MVVM и замена Icommands Для обработчиков событий.

Кроме того, нет «лучшей практики» для установки обработчиков событий, декларивно в XAML или через код в конструкторах. Это зависит от вас.

Я бы подумал, что Большинство людей ожидают увидеть декларации в XAML, видя как именно здесь, где вы проектируете UI.

2
ответ дан 2 September 2019 в 05:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: