我是.NET的網頁開發新手，我目前正在學習一個頁面，在這裏我分開了代碼隱藏（在我的情況下，一個與ASPX文件關聯的.CS文件），以及代碼隱藏在ASPX文件中的標籤是這樣的：ASP.NET中的<script>標記功能有多強大？
<script runat="server">
//code
</script>
Q1：主要區別（除了像組織，可讀性和ETC邏輯事項），什麼可以在不能在另一個做一個方式來完成是什麼？每種模式最適合什麼？
Q2：如果我要開發一個具有數據庫連接，圖書館進口，訪問控制（ASCX）和圖像接入到其它文件夾一個簡單的頁面..這方法我應該選擇？
任何你在代碼隱藏方面都可以做的事情，你可以在你發佈的內嵌腳本中做。但是無論如何，你應該在大部分時間使用代碼。有些東西（如使用指令）在這裏稍微簡單一些，它有助於保持代碼的組織性。
保持分離。使用.aspx頁面進行佈局，使用.aspx.cs頁面來訪問任何頁面特定的代碼，並且首選將數據訪問/業務邏輯拉出到自己的層中，以便稍後進行更簡單的維護/重用。
輕微的警告有 - ASP.net MVC使用它的意見內嵌腳本，我已經真的來了一輪這一想法 - 它可以保持簡單的東西簡單，但在MVC中使用的架構確保您的業務代碼仍與演示代碼分開。
我並不是說你應該破解實時代碼......但是，將「後面的代碼」作爲內嵌腳本的一點靈活性在於，你可以修改而不必重新編譯/發佈現場。
就我個人而言，我從來沒有這樣做，但我聽說過人們已經做好了緊急修復的實例。
我已經在編譯的1.1網站上完成了它，我沒有源代碼（比如在家工作或者在工作時間之後）有些東西被洗淨了。這並不總是一種選擇，它取決於它是什麼類型的問題。通常情況下，我會暫時打補丁，然後將其發送給項目實際屬於第二天的任何人，以便將其永久集成到後面的代碼中。 – 2010-03-31 13:44:49
腳本標記和背後的代碼沒有區別。選項後面的代碼實際上是使用腳本標籤或「經典ASP」中的<% %>。許多開發人員不喜歡這樣一個事實，即他們將服務器端代碼放在UI代碼旁邊，因爲它使得文件看起來很亂，而且對於HTML人員（網頁設計師或任何您想要的打電話給他們）與開發人員同時在同一頁面上開發。大多數人喜歡使用後面的代碼（它實際上被認爲是標準的做事方式），因爲它保持了用戶界面和代碼的獨立性。這是我喜歡的，但你真的可以使用。
有趣的是，我以前在代碼中<script runat="server">今天盈方只！我這樣做是因爲您不需要構建整個Web應用程序來部署需要後臺代碼的修復程序。是的 - 這是一個錯誤修復;）
Q1：沒什麼。除了你和其他人提到的內容（分離，可讀性），你可以做任何「後面的代碼」都可以用「內聯」（頁內本身的代碼）編碼來完成。
聯機編碼並不一定意味着它的UI和代碼混合在一起的像「意大利麪代碼」（像老式ASP）。你所有的代碼都可以在UI/HTML之外生存，但仍然是內聯的。您可以將所有代碼隱藏代碼複製/粘貼到您的內聯頁面並進行一些調整（佈線，命名空間，導入聲明等），就是這樣。
其他評論指出：可移植性和快速修復/修改。 根據您的使用情況，您可能不希望某些代碼段暴露（專有），但可供使用。這對於web開發專業人員來說很常見。內聯代碼允許您的客戶以任何他們想要的方式快速/輕鬆地定製功能，並且可以隨時使用您的某些（專有）庫（dll），而無需使用代碼運行庫（如果它們是，它們不會首先僱傭了你）。
所以實際上，它就像發送一個「html」文件給客戶端，包含關於如何改變事物的指令（而不會破壞事物）......而不是發送源代碼文件以及html（aspx）頁面並希望你的客戶知道如何處理他們......
Q2：無論是任何風格（內聯或代碼隱藏）都可以工作，它真的是在「層」看你的應用程序的問題。通常，這將是：UI，業務邏輯和數據層。以這種方式思考事情會爲你節省很多時間。
實際的例子：
在上面的例子中，你已經將很多處理「分離」到了自己的層中。然後，您的個人html/aspx頁面可以在「頁面級」使用「代碼庫」（數據和輸入驗證）以最少的代碼快速使用。然後，在「頁面級」使用內聯或代碼隱藏樣式的決定無關緊要 - 您基本上已將它「貶低」到當時的任何用例。
希望這會有所幫助....
由於邏輯問題，我總是使用代碼隱藏文件。 （我沒有很好的回答你的問題，所以我選擇了一個評論。） – Greg 2010-03-31 13:32:24