2008-08-25 28 views

Trả lời

18

Có một số phạm vi có sẵn cho bất kỳ phần nào của mã của bạn: Phiên, Khách hàng, Cookie, Ứng dụng và Yêu cầu. Một số không được sử dụng theo các cách nhất định (tức là sử dụng phạm vi Yêu cầu hoặc Ứng dụng bên trong Thẻ tùy chỉnh hoặc CFC của bạn; đây là coupling, vi phạm nguyên tắc đóng gói và được coi là thực hành không tốt) và một số có mục đích đặc biệt: Cookie được lưu giữ trên máy khách máy như cookie vật lý và các biến phạm vi phiên là người dùng cụ thể và hết hạn với phiên của người dùng trên trang web.

Nếu biến không thể thay đổi (hằng số cho mọi mục đích và mục đích) và có thể đơn giản được khởi tạo khi khởi động ứng dụng và không bao giờ được viết lại, thường bạn nên đặt nó vào Phạm vi ứng dụng vì điều này vẫn tồn tại giữa mọi người dùng và mọi phiên. Khi thực hiện đúng, nó được viết một lần và đọc N lần.

Một thực hiện đúng các biến Application trong Application.cfm có thể trông như thế này:

<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> 

Lưu ý rằng sự tồn tại của các biến trong phạm vi ứng dụng sẽ được kiểm tra trước và sau khi khóa, do đó nếu hai người dùng tạo điều kiện chạy đua khi khởi động ứng dụng, chỉ một trong số chúng sẽ kết thúc thiết lập các biến ứng dụng.

Lợi ích của phương pháp này là nó sẽ không liên tục làm mới các biến được lưu trữ này trên mọi yêu cầu, lãng phí thời gian của người dùng và chu kỳ xử lý của máy chủ. Thương mại là nó là một chút tiết và phức tạp.

Điều này đã được đơn giản hóa rất nhiều với việc bổ sung Application.cfc. Bây giờ, bạn có thể chỉ định các biến được tạo ra khi khởi động ứng dụng và không cần phải lo lắng về khóa và kiểm tra cho sự tồn tại và tất cả những thứ vui vẻ:

<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> 

Để biết thêm thông tin về Application.cfc bao gồm tất cả các các chức năng đặc biệt khác nhau và mọi chi tiết nhỏ về cách sử dụng, I recommend this post on Raymond Camden's blog.

Để tóm tắt, phạm vi yêu cầu có sẵn ở mọi nơi trong mã của bạn, nhưng điều đó không nhất thiết làm cho nó "đúng" để sử dụng ở mọi nơi. Rất có thể là người tiền nhiệm của bạn đã sử dụng nó để phá vỡ đóng gói, và có thể cồng kềnh để cấu trúc lại. Bạn có thể là tốt nhất để lại nó như là, nhưng sự hiểu biết phạm vi nào là công cụ tốt nhất cho công việc chắc chắn sẽ làm cho mã tương lai của bạn tốt hơn.

15

Đây là một câu hỏi rất chủ quan, và một số thậm chí còn cho rằng không bao giờ "thích hợp" để sử dụng phạm vi yêu cầu trong các ứng dụng Coldfusion hiện đại.

Với tuyên bố từ chối trách nhiệm đó, hãy xác định phạm vi yêu cầu là gì và nó sẽ hữu ích ở đâu.

Phạm vi yêu cầu là phạm vi toàn cầu tuyệt đối trong một yêu cầu trang ColdFusion đơn lẻ. Nó không phải là một phạm vi chia sẻ, giống như ứng dụng, máy chủ, máy khách và phạm vi phiên, vì vậy khóa không cần thiết để làm cho luồng an toàn (trừ khi bạn sinh ra các chuỗi công nhân từ một yêu cầu duy nhất sử dụng thẻ CFTHREAD của CF8). Là một phạm vi toàn cầu, nó là một cách rất thuận tiện để duy trì các biến thông qua bất kỳ cấp độ nào trong ngăn xếp của yêu cầu mà không phải chuyển chúng từ cha mẹ sang người gọi. Đây là một cách rất phổ biến để duy trì các biến thông qua Thẻ tùy chỉnh lồng nhau hoặc đệ quy trong các ứng dụng CF cũ hơn.Lưu ý rằng mặc dù nhiều ứng dụng sử dụng phạm vi này để lưu trữ các biến cấp ứng dụng (ví dụ), chênh lệch lớn (và đôi khi tinh tế) giữa phạm vi yêu cầu và phạm vi ứng dụng là giá trị của cùng một yêu cầu biến phạm vi có thể khác nhau giữa các yêu cầu trang riêng lẻ.

Tôi đoán rằng người tiền nhiệm của bạn đã sử dụng phạm vi này làm phương tiện để đặt các biến cần thiết để tồn tại nhảy giữa các đơn vị mã được đóng gói hoặc lồng nhau mà không phải chuyển chúng một cách rõ ràng.

0

OK, tôi chỉ muốn nhận xét về mã của bạn. Xin hãy tha thứ cho tôi nếu tôi có vẻ điên rồ. Nhưng bạn đã xác minh rằng structKeyExists ở đầu. Vì bạn biết nó sẽ là đúng, nó sẽ không có ý nghĩa để chạy kiểm tra khác. Vì vậy, phiên bản của tôi của nó sẽ là ... Nhưng đó chỉ là tôi.


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

Được rồi.

+0

Thực tiễn tốt nhất bắt buộc bạn kiểm tra lại trong cflock để tránh điều kiện chủng tộc –

+2

"Thực hành tốt nhất" để đặt biến phạm vi ứng dụng vì CFMX6.0 chỉ sử dụng CFLOCK có khả năng xảy ra tình trạng chủng tộc không có trong mã được cung cấp ở đây. Nếu người ta chỉ muốn đặt một giá trị đơn giản thành biến ứng dụng và toàn bộ quá trình là nguyên tử (nghĩa là: đó là một câu lệnh và không có phạm vi cho điều kiện chủng tộc, như trong ví dụ này), chỉ cần sử dụng thẻ CFPARAM khỏe. –

0

Tôi đã viết khung công ty của mình sẽ được sử dụng để cấp nguồn cho trang web của chúng tôi.

Tôi sử dụng biến yêu cầu để đặt dữ liệu nhất định sẽ có sẵn cho các CFC khác của tôi, vì vậy dữ liệu sẽ có sẵn trong suốt ứng dụng mà không cần phải liên tục truyền dữ liệu. Tôi thành thật tin rằng bằng cách sử dụng yêu cầu, và ứng dụng miễn là một thành phần chức năng tĩnh của nó thì bạn không nên có một vấn đề. Tôi không chắc liệu mình có sai lầm trong suy nghĩ của mình với điều này hay không nhưng một khi tôi phát hành khung công tác, chúng ta sẽ thấy.

Các vấn đề liên quan