2013-03-13 2 views
3

Я разрабатываю приложение LightSwitch 2012 для управления запросами, и я хочу иметь возможность обновлять состояние запроса с помощью того же многоразового кода на всех моих экранах. Например, пользователь может изменить состояние запроса на экране утверждения, экране выполнения и т. Д., Которые вызываются кнопкой. В настоящее время у меня есть метод в каждом из файлов .cs, где мне нужно обновить запрос, используя методы partial void <ScreenCommand>_Execute(). Я пытаюсь изменить это, поэтому я могу обновить код из одного места, а не везде, и мне также не нужно копировать методы на новые экраны, на которые я добавляю кнопку. Теперь я обычно помещал это в Application.cs или в другое место с глобальным доступом, но у меня нет доступа к тому же объекту DataWorkspace. Я также передаю объект this.DataWorkspace с экрана, что позволяет получить доступ к методу SaveChanges(). Однако это кажется немного вонючим. Есть ли лучший способ справиться с этим или лучшим местом для размещения повторно используемых команд, которые вы хотите назначить кнопкам на нескольких экранах? В настоящее время я должен быть очень осторожным с сохранением грязных данных, и мне все равно придется подключать все вручную. Я также не знаю, работает ли код в соответствующем контексте, если он находится в файле Application.cs. Чтобы уточнить, да, я хочу, чтобы это выполнялось на стороне клиента, поэтому я могу запускать электронные письма из своих почтовых ящиков Outlook и т. П.Повторное использование общей команды в нескольких экранах подсветки

ответ

2

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

Вы можете добавить код в модуле (или статического класса в C#) в USERCODE папку Client проекта. Это часть причины, по которой папка существует, как место для размещения «кода пользователя». Для этого перейдите на . Просмотрите файл, затем щелкните правой кнопкой мыши папку UserCode, чтобы добавить свой модуль/класс. Добавьте свой метод во вновь созданный модуль/класс. Вы можете создать столько из них, сколько хотите (если вам нравится разделять код), или вы можете добавить другие методы в один и тот же модуль/класс, это зависит от вас.

Однако я не стал бы пропускать рабочее пространство данных в качестве параметра для создаваемого вами метода многократного использования. Я бы даже не передал объект объекта, просто значения, необходимые для вычисления требуемого состояния. Но фактический вызов метода рабочей области SaveChanges должен оставаться в коде экрана. Подумайте о экране как «блок работы».

В Execute метода каждой кнопки (в ваших различных экранах), вызов методы со значениями от лица манипулирует в экране & возвращает результат. Присвоить вычисленное возвращаемое значение государственного имущества предприятия (если это то, что у вас есть), а затем вызвать Сохранить метода, экрана (или использовать Закрыть его метод экрана, передавая верно для SaveChanges параметра). Вам не нужно вызывать метод SaveChanges, который вы делаете «способ LightSwitch», делая это так.

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

Надеюсь, что все имеет смысл для вас.

+0

ОК, я понимаю, что вы говорите, однако, я полагаю, что мое основное опасение заключается в вызове метода Application.Current.CreateDataWorkspace(). Это дорогостоящая операция? Если я проверяю свойство напр. мой объект запроса (скажем, я хочу отфильтровать мои запросы только теми, где у пользователя есть соответствующее разрешение для обработки, например), и я вызываю это в предложении where, создаст ли это создание DataWorkspace проблемы с производительностью? – DTreth

+0

Это новый вопрос? Нигде в чем-то, что я объяснял, я не упомянул о необходимости использования CreateDataWorkspace, а также в вашем вопросе. Если вы правильно используете экран в качестве единицы работы, вам не нужно создавать CreateDataWorkspace, так как на каждом экране всегда есть собственное пространство данных. –

+0

Тогда, может быть, я должен отредактировать свой вопрос. Если я переведу код, у меня больше не будет объекта 'this.DataWorkspace', чтобы выбрать правильный атрибут для свойства. Я не упоминал, что я использовал его как: 'request.RequestState = DataWorkspace.DataSource.RequestStates.Where ((r) => r.StateName == newStateName) .Single()' – DTreth

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