關於 Code Behind 與 Code Inline 開發模式的使用時機與技巧

  分享到噗浪!

大家應該都知道從 ASP.NET 2.0 開始有區分 Code BehindCode Inline 兩種開發模式,對我個人來說我兩種都喜歡,且各有各的使用時機,並不會完全使用 Code Behind 進行程式開發。

Code Behind 開發模式的使用時機

  • 程式碼多、頁面中使用到較多的控制項事件,因為 Visual Studio 中的方法切換很方便
    Visual Studio 中的方法(Method)切換很方便
  • 頁面邏輯較複雜
  • 需要繼承較複雜的 BasePage 或需實做介面(Interface)

Code Inline 開發模式的使用時機

  • 程式碼少(有些頁面中的控制項幾乎用宣告的方式就可以完成,完全不用寫 Code)
  • 頁面中使用到較少的控制項事件
  • 頁面邏輯簡單

雖然我有以上的使用時機的判斷依據,但我個人還是比較偏好 Code Inline 的開發方式。

例如以下 Code Inline 的程式碼範例,明明這一頁只有一個 Page_Load 事件,何必要多新增一個 Code Behind 檔案呢,這種情況我通常都直接改用 Code Inline 的方式來寫,並且把 Code Behind 的 *.aspx.cs 檔刪除。

Code Inline 開發模式

另外,我們要替頁面上的控制項加上事件(Event)時,通常會用以下 3 種方法:

  1. 透過 Visual Studio 的 Design View (設計檢視) 透過 UI 加上事件(雙擊控制項或透過屬性視窗)
  2. 透過Visual Studio 的 Source View (原始碼檢視) 手動在控制項上面加上事件宣告,再去程式碼區新增事件方法
  3. 直接在頁面的 Page_Init 事件手動註冊控制項的事件(如下圖):
    直接在 Page_Init 註冊控制項的事件
    直接在 Page_Init 註冊控制項的事件

通常我只會用第 1 種與第 3 種方法,第 2 種太麻煩了。我在使用 Visual Studio 開發 ASP.NET 網站時,幾乎不會切換到 Design View (設計檢視),因為速度實在是太慢了。在很久以前,我會切到 Design View 的唯一理由就是要新增控制項的事件,不過現在也很少使用第 1 種方式新增事件了。所以我幾乎都是用「第 3 種」方法宣告事件的。

我覺得 C# Developer 應該很少人知道上述「第 2 種」新增事件的方法在 Visual Studio 中其實有個操作訣竅!只要你的頁面採用的是 Code Inline 的方式開發,就可以在 Visual Studio 左上角的開發視窗看到 Server Objects & Events 項目,而且會列出所有控制項出來。

在 Visual Studio 左上角的開發視窗看到 Server Objects & Events 項目,而且會列出所有控制項出來 

先選完控制項之後,在右邊的下拉選單就會出現該選單的所有可用事件:

Visual Studio 選完控制項之後,在右邊的下拉選單就會出現該選單的所有可用事件

點選完事件之後事件,在 Code Inline 的程式碼區就會自動新增該控制項的事件方法架構,而且控制項也會自動加上相對應的宣告屬性,是不是方便很多呢!

點選完事件之後事件,在 Code Inline 的程式碼區就會自動新增該控制項的事件方法架構

<asp:Button ID="BtnSend" runat="server" Text="送出" OnClick="BtnSend_Click" />

上述這一招我是從一篇 VB.NET 的教學影片學來的,但因為我之前也都是使用 Code Behind 的方式在開發,所以 Server Objects & Events 項目永遠不會出現,有一次改成 Code Inline 的時候突然發現原來用 C# 開發也可以用這種開發方法,真的是太方便了!^_^

小故事分享

我之前曾經做過一個 ASP.NET 專案,等到專案交付原始碼的時候,客戶看到我們的網站竟然大部分頁面都是用 Code Inline 的方式開發的,然後劈頭就問我說「你們怎麼用 ASP 的模式在開發程式,寫 ASP.NET 不是就應該 Tag 與 Code 分離嗎?」總之就是一副認為我們寫的程式很糟糕的樣子。

用 Code Inline 的開發方式並不等於 Code 與 Tag 混雜(Spaghetti code),只是程式碼與標籤放在同一個檔案裡而已。

我想他不是被 ASP 嚇到過,就是中 ASP.NET 的毒太深,然而這也是另一個知其然不知所以然的例子,希望各位開發人員能有所體悟,有時後 Know Why 比 Know How 更重要。

此文章由 will 發表於 2008/12/23 下午 08:25:41

永久連結 | 評論 (9) | 此文章的RSSRSS comment feed |

分類: ASP.NET | C# | Visual Studio

標籤: , ,

評論

十二月 24. 2008 10:24

tiebob

code behide 的一個主要原因是為了畫面設計可以切割開來,不知 will 兄利用 code inline 有沒有遇到這方面的困擾?

tiebob Taiwan

十二月 24. 2008 16:09

Jason

保哥你好,看到這篇,想請問一下,如果一個案子中

某些頁面用Code Behind,某些頁面用Code Inline

這樣子是否會造成維護人員的困擾?

Jason Taiwan

十二月 24. 2008 16:50

will

tiebob,
難道你們畫面設計好之後給工程師套完程式後,該網頁還會給設計師改嗎?就算是 Code Behind 我也不敢把頁面交給設計師,我怕他們把控制項給搞亂了,你知道有些網頁編輯軟體很"壓給"的!(編按:壓給 == 多此一舉)

所以我們在工作上並無此困擾,我們的工作流程是:
1. 先由網頁設計師提供網頁版面(含 MasterPage 套版)
2. 再由程式設計師進行程式套版(Code Behind 或 Code Inline)

will Taiwan

十二月 24. 2008 16:51

will

jokkson,
完全不會,不知道你的困擾在哪裡?

will Taiwan

十二月 24. 2008 16:57

tiebob

如果是一次性的美工,code behide 或 code inline 都是自己處理,不過,如果是需要和美工一來一往的話,code inline 大概就會有一點點困擾。

不過,目前我也都和 will 兄一樣,美工先設計完後,後續的部分就自己來了~~~~~不曉得這算不算是多能者多勞 :>

tiebob Taiwan

十二月 24. 2008 17:24

will

其實,如果你們是需要一來一往的話,用 Code Inline 應該也不會影響太多的,只要你確認網頁編輯工具不會改到 script runat="server" 程式碼內的內容即可。我以前實驗的時候,好像不會動到喔,你可以自己實驗看看,有好消息可以再跟我說。 ^_^

will Taiwan

十二月 24. 2008 18:43

Jason

剛漏看一行"把 Code Behind 的 *.aspx.cs"
所以說只要是沒有 *.aspx.cs的Page就是Code Inline
這樣子應該就比較好了解了。

Jason Taiwan

十二月 24. 2008 21:56

leem

保哥你好,請問你用Code Inline開發時,那編譯時是用可編輯網站的方式編譯嗎?還是連ASPX的內容都一起編譯進DLL中呢?謝謝!

leem Taiwan

十二月 24. 2008 22:57

will

大多都是用可編輯網站的方式編譯

will Taiwan

新增評論


( 您輸入的Email不會顯示於網站上 )

  Country flag

biuquote
  • 評論
  • 線上預覽
Loading