配置驗證在.NET

Question

我執行一個系統監視項目稍微複雜的配置部分：

<monitoring> 
    <components> 
    <component name="Remote Server" 
       statusProviderType="ClientEndpoint" 
       statusProviderName="endpoint1" /> 
    </components> 
</montioring> 

<system.serviceModel> 
    <client> 
    <endpoint name="endpoint1"/> 
    <!-- Config removed for brevity --> 
    </client> 
</system.serviceModel> 

如在上面的例子中，這些配置元素可以參考其他配置元素。在這種情況下，客戶端端點必須實施作爲監控項目一部分的預定合同。

內置配置處理處理任何明顯的語法錯誤和值超出有效範圍的簡單錯誤。問題是配置是更復雜的錯誤的來源：

• 引用一個不存在的元素。
• 引用不符合某些條件的類型。

很明顯，我希望撿起這些錯誤，但應該在應用程序中進行驗證？

我目前考慮這些選項，但我不知道任何人是正確的：

• 配置元素驗證本身和在讀它拋出異常。將所有內容保持在配置級別，但在嘗試「構建」配置節以將其寫入配置文件時會引入問題。
• 使用配置的組件會在配置值傳遞給它時驗證配置值，並根據收到的信息拋出異常。允許配置元素具有更大的靈活性，但更難確定問題的來源。
• 使用配置的組件驗證其操作所需的配置，並在配置無效時拋出異常。這很好地將行爲從配置中分離出來，但是當配置成爲問題的根源時，它就不那麼明顯了。

此外，哪些異常適合拋出我可能處理的錯誤種類？獎金積分與你的答案有很好的推理。我很想知道所有可用的選項，但知道如何配置可以調試一些系統，我真的想要一個明智的解決方案。

Answer 1

我就走了，問了一些同事，調查了.NET類如何處理這類問題，來到了一些澄清：

• 配置是一個簡單的方法來配置對象實例，常作爲很簡單，就是爲新實例指定默認值。配置文件中的可用值通常也可用於在代碼中設置。
• 配置不當的實例拋出InvalidOperationException並派生類指示對象狀態中的錯誤。它不表示，其中配置問題來自。
• 如果配置的有效性足以設置實例，即使實例無法正確運行，該錯誤也不再被專門分類爲「配置文件」問題。

顯然，這給了我一些規則，我可以堅持，值得高興的事情我的配置系統：

• 如果錯誤可以在配置文件中的值內被檢測（如串以不正確的格式，不實現接口的類型），錯誤是配置級錯誤並指示配置文件有問題。應該由配置部分執行驗證，並在從配置文件中讀取部分時引發異常。
• 如果在一個值內不能檢測到錯誤，應該可以從這些值中初始化一個實例，而不會拋出任何異常。避免在這裏拋出異常，並考慮重構類將現有異常移到別處。在這個階段，與配置無關的異常很難調試，因爲通常沒有可用的狀態來調試。如果在這裏拋出異常必須，它們應該由與配置相關的異常包裝，並應引用導致問題的元素。
• 如果在加載配置後發生任何錯誤，則該問題將由對象實例作爲InvalidOperationException或類似問題處理，因爲它不知道它的工作值來自哪裏，因此只能指示其狀態不正確。

其他人應該做複雜的配置，我希望這有助於。

Answer 2

使用DTD和XML驗證工具。 Here is the description