2009-09-11 53 views
2

在從傳統的ASP到Asp.Net一些開發商走上把自己的服務器端代碼塊在其HTML翼上方的轉變:Asp.Net在線(單文件)與代碼隱藏

<%@ Import Namespace="MyDll" %> 

<script runat="server"> 
    void Page_Load() 
    { 
    } 
</script> 

此單頁模型具有一定的優勢爲Jeff Atwood describes,但是,在我的經驗,我已經看到了幾乎所有的代碼放在一個單獨的代碼隱藏文件在近期(即在VS 2008)。

然而,事實證明,一個同事強烈傾向於在單獨的代碼隱藏方法中的單個文件(內聯)方法。

每種方法的優缺點是什麼? (我注意到代碼崩潰和#區域似乎不被支持,而且頁面變得很長,不再有客戶端和服務器端代碼的可視分離,你能告訴我有一個偏好嗎?)

我意識到這個問題的變化之前已經被問到過了,但是我沒有看到有人真正明確了每種方法的優缺點。

編輯

謝謝大家對你的發人深省的答案。我仍然希望列出每種方法的長處和弱點。什麼是每個(或沒有)的實際功能?

回答

1

通常,在WebForms中工作時,我所看到的趨勢是使用代碼隱藏。我在該領域見過的許多* WebForms應用程序都有太多的代碼隱藏,爲了能夠理解所有的邏輯,分離幾乎是至關重要的。

但是,在一個設計良好的應用程序中,用戶界面只是在執行UI作業,並將所有邏輯和繁重程序傳遞到不同的應用程序層,因此單個文件解決方案通常會更加優雅和簡單足以遍歷。從某種意義上說,使用單一文件解決方案可能會 - 在正確的手中 - 激發更好的問題分離,因爲您不希望那個文件(它提供了您的UI)混雜在一堆業務中邏輯。

在ASP.NET MVC模型中,默認值是單個文件。這又是爲了強調關注點和良好應用設計的分離。 (如果ASP.NET MVC工具包提供了一個代碼隱藏的概念,我不知道該如何處理我的頭頂問題。如果有的話,我還沒有使用它。)

最終,YMMV。優秀的開發人員無論使用代碼隱藏還是單一文件模式都傾向於編寫出色的代碼。糟糕的開發人員也傾向於編寫糟糕的代碼。

*顯然不是全部!

+0

非常好的一點,雖然在足夠複雜的頁面上提供了足夠的回發事件,但我已經看到,即使是乾淨的代碼隱藏也相當大。 – 2009-09-11 20:27:54

+1

的確如此。然而,在這一點上,更好的設計是開始將東西分解成用戶控件,並將頁面上的用戶控件連接起來以相互交流。更多的努力,但絕對容易維護。 – 2009-09-11 20:29:10

4

由於代碼隱藏只是一個類,它具有所有優點,如評估和界面。它還增強了可讀性。

對於專注於輸出數據而不是執行businesslogic的應用程序,單頁大多已被mvc所取代。

+0

好點,mvc確實回到了經典的asp思維方式(雖然有很大的改進)。 – 2009-09-11 20:25:33

+1

錯誤的是,MVC將業務邏輯帶入了業務類(模型),而不是將其與「單一頁面」中的表示混合,即spagetti風格。 – queen3 2009-09-11 20:34:07

5

毫無疑問,在我看來,代碼隱藏或mvc模型對於幾乎所有您想要做的事情都是優越的。但是,即使在今天,我仍然發現自己在大多數頁面上使用內聯代碼。爲什麼?因爲有一個內聯腳本真正發光的大場景。

如果您有大量遺留的ASP Classic代碼,您不想丟棄它們,包括深層嵌套結構,它們都存在於一個大的應用程序中,並且您希望與您的asp共享該應用程序.net代碼,您可以直接將內聯asp.net頁面放入現有的Web文件系統中,它們就會正常工作。

這聽起來像你的其他開發者來自哪裏。

+0

我沒有想到這一點。在我們的例子中,我們不保留傳統的ASP代碼。我們所有的代碼至少是.NET 2.0或更高版本。 – 2009-09-11 20:24:43

2

您是否考慮過查看ASP.NET MVC?它會讓你在非常乾淨的分離中克服這種困境。

+0

當然,我們正在研究MVC,但我真的很想知道每種方法的具體優缺點。 – 2009-09-11 20:28:47

-1

內嵌代碼是程序性的,缺乏的關注點分離...

一個ASP.Net的賣點是後臺代碼和服務器控件。內聯代碼被認爲是不好的。當ASP.NET Mvc出現時,這種情況發生了變化 - 內聯代碼再次變爲「時髦」。

如果我有一個選擇,並且所有使用代碼隱藏的東西都是相同的,那麼這是一個更好的方法。我努力保持UI的邏輯/代碼不變。

即使使用代碼隱藏,雖然它是一個類,它可能會變得混亂。我發現,使用MVP或MVC的一些變體與Web表單使得開發在長期內更易於維護。