2008-08-25 2 views

ответ

18

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

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

Надлежащая реализация переменных приложения в Application.cfm может выглядеть следующим образом:

<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
     <cfif not structKeyExists(application, "dsn")> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
     </cfif> 
    </cflock> 
</cfif> 

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

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

Это было значительно упрощено с добавлением Application.cfc. Теперь, вы можете указать, какие переменные создаются при запуске приложения и не придется беспокоиться о блокировке и проверка на существование и все это позабавимся:

<cfcomponent> 
    <cfset this.name = "myApplicationName" /> 

    <cffunction name="onApplicationStart" returnType="boolean" output="false"> 
     <cfset application.dsn = "MyDSN" /> 
     <cfset foo = "bar" /> 
     <cfset x = 5 /> 
     <cfreturn true /> 
    </cffunction> 
</cfcomponent> 

Для получения дополнительной информации о Application.cfc включая все различные специальные функции и каждая мелочь о том, что и как ее использовать, I recommend this post on Raymond Camden's blog.

Подводя итог, область запроса запрашивается везде в вашем коде, но это не обязательно делает ее «правильной» для ее использования повсюду. Скорее всего, ваш предшественник использовал его для разрушения инкапсуляции, и это может быть громоздким для реорганизации. Возможно, вам лучше оставить его как есть, но понимание того, какая область является лучшим инструментом для работы, определенно сделает ваш будущий код лучше.

15

Это очень субъективный вопрос, и некоторые даже утверждают, что никогда не «целесообразно» использовать область запроса в современных приложениях ColdFusion.

С этим отказом от ответственности давайте определим, что такое область запроса и где это было бы полезно.

Область запроса является абсолютной глобальной областью в одном запросе страницы ColdFusion. Это не общая область видимости, как приложения, сервер, клиент и сеансы, поэтому блокировка не требуется, чтобы сделать ее потокобезопасной (если только вы не создаете рабочие потоки из одного запроса, используя тэг CFTHREAD CF8). Как глобальная область применения, это очень удобный способ сохранения переменных на любом уровне в стеке запроса без необходимости передавать их от родителя к вызывающему. Это был очень распространенный способ сохранения переменных через вложенные или рекурсивные пользовательские теги в старых приложениях CF.

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

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

0

Хорошо, я просто хотел прокомментировать ваш код. Пожалуйста, простите меня, если я буду казаться сумасшедшим. Но вы уже подтвердили, что structKeyExists в начале. Поскольку вы знаете, что это будет правдой, было бы бессмысленно запускать еще одну проверку. Так что моя версия будет такой ... Но это только я.


<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
    </cflock> 
</cfif> 

Хорошо.

+0

Рекомендации по лучшей практике, которые вы проверяете снова в рамках cflock, чтобы избежать условий гонки – 2010-08-11 22:20:38

0

Я пишу рамки моей компании, которая будет использоваться для питания нашего сайта.

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

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