2008-09-16 29 views
7

如果我使用下面的代碼我失去權代碼點擊變量後面,重構(在這種情況下,重命名)他們aspx頁面中的內聯代碼是一種很好的做法嗎?

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a> 

我到處都看到這種做法的能力,但它似乎怪我,我如果我更改屬性名稱,不再能夠獲得編譯時錯誤。 我的首選的方法是做這樣的事情

<a runat="server" id="MyLink">Edit</a> 

,然後在後面

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id; 

我聽到的話讓人覺得上面的方法是自認爲更好真正感興趣的代碼是什麼,我總是看看流行的編碼網站和博客(例如Scott Guthrie),它的代碼較小,但我傾向於使用ASP.NET,因爲它是編譯的,並且更願意知道在編譯時是否有某些內容被破壞,而不是運行時。

回答

4

我不會說這是不好的做法(有些人會不同意,但他們爲什麼首先給我們這個選擇?),但是我會說如果你不提交這個,你會提高整體的可讀性和可維護性實踐。您已經提出了一個很好的觀點,那就是IDE功能限制(即設計時間檢查,編譯時間警告等)。

我可以繼續討論它違反了多少原則(代碼重用,關注點分離等),但我可以想到許多應用程序,幾乎可以打破所有原則,但在數年之後仍然有效。我首先想要使我的代碼儘可能模塊化和可維護。

+0

「但他們爲什麼首先給我們提供這樣的選擇?」因爲這是ASP 3.0如何做到的?我們通過C#使用VB.NET單板有一個原因。微軟往往非常認真地向後兼容並維護以前的心理模型。正如你正確地指出的那樣,能夠編寫像代碼一樣的ASP 3並不一定是一個好主意! – ruffin 2013-03-08 22:05:10

1

它被稱爲意大利麪代碼,許多程序員覺得它令人反感......如果你和公司的其他開發人員發現它是可讀和可維護的,那麼我該告訴你該怎麼做。

可以肯定的,雖然,用途包括向減少冗餘(DRY - 不要重複自己)

0

這是給你的。有時候,「簡單代碼」代碼比建立/使用完整的模板系統更容易維護,但是一旦你獲得了相當複雜的頁面,或者更具體地說,一旦你開始在頁面本身中包含大量邏輯,它就可以獲得髒很快。

0

我認爲有趣的是,更多的asp.net需要aspx頁面中的代碼。 3.5中的listview,甚至ASP.NET MVC。 MVC基本上沒有代碼,但在頁面中編碼來呈現信息。

1

我只是偶爾使用它,一般是因爲某些特殊原因。我將永遠是一個快樂的開發者,我的代碼完全從我的HTML標記中分離出來。這有點個人偏好,但我認爲這是一個更好的做法。

0

如果您從模板開發的角度來考慮它,那麼明智地將它保留在視圖中,而不是保留在代碼背後。如果需要使用不引人注意的JS來處理點擊,需要從錨點更改爲列表項?是的,這不是最好的例子,而僅僅是這個例子。

我總是試着根據我是否有一個設計師(HTML,CSS,任何東西)來思考,我會讓他做什麼以及我會在後面的代碼中做什麼,以及我們如何不分階段別人的腳趾。

0

它只是一個壞習慣,如果你不能很好地封裝它。

像其他事物一樣,你可以創建討厭的,不可讀的麪條代碼,但現在你必須標記含量,其設計是不是世界上最可讀的東西。

我嘗試並保持if如果超出hte模板的數量,但是過多的封裝會導致必須查看13個不同的位置,以瞭解爲什麼div x不向客戶端發射,所以它是一種折衷。

0

這不是,但有時它是一個必要之惡。

以你的情況爲例,雖然後面的代碼似乎有一個值得關注的更好的分離,但它存在的問題是,它可能無法分離出關切清楚你的願望。通常當我們做代碼背後的代碼時,我們不是在MVC框架中構建應用程序。至少與MVC相比,代碼背後的代碼也不易維護和測試。

如果您正在構建ASP.NET MVC應用程序,然後我想你一定堅持內聯代碼。但是,在可維護性和可測試性方面,以MVC模式構建是最好的方法。

綜上所述:內嵌代碼是不是一個好的做法,但它是一個必要之惡。

我的2cents。

0

通常,我喜歡用這種方式。

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'> 
相關問題