我在asp.net中構建了一個新的基於web的應用程序。我們的後端具有返回JSON的現有WCF/REST服務。我也有一個JavaScript庫，爲我的客戶端調用/使用這些JSON服務。這使應用程序可以進行客戶端AJAX調用，並執行客戶端中繼器之類的操作（Rick Strahl發佈了關於如何使用jQuery的方法）。這工作得非常好，並提供了一個活潑的Web 2.0感覺。通過jQuery將更多的Web演示邏輯轉移到JavaScript
問題是，鑑於我有後端，和一個JS庫的管道 - 我應該建立所有我的主要列表控件和其他功能完全客戶端？我已經用它創建了幾頁，並且在我的代碼中看不到任何東西，這有點令人不安！我試圖獲得關於這種方法的優點和缺點的意見。
同樣，JS庫的構建，後端的構建 - 所以它只是一個問題，我應該使用jQuery（客戶端中繼器等）或更傳統的服務器端方法構建頁面和邏輯。
想法和建議是非常受歡迎的！
您能否確保您的觀衆在瀏覽您的網站時始終啓用JavaScript？如果你可以做出這樣的要求，那麼繼續前進，並在JS中做前端，如果你認爲它會更容易。如果你不能保證，那麼你需要做到服務器端，所以沒有JavaScript的用戶實際上可以看到輸出。你不想要一堆沒有出現的人，對吧？
我對這種方法很感興趣。它可以讓你匆匆地顯示頁面，並懶洋洋地顯示列表和存儲庫中的其他東西。
建立一切客戶端肯定有一些負面影響。對於使用屏幕閱讀器的視力受損用戶而言，它可能會導致問題 - 讀者通常支持一些但不是全部的JavaScript。至少應該使用屏幕閱讀器來嘗試網站。我相信它也會影響搜索引擎索引 - GoogleBot或類似的網絡爬蟲不會在頁面上看到任何內容。
我已經使用了一些以這種方式工作的調查軟件，我也可以說它使客戶端的調試變得非常痛苦。
可以有一箇中間地帶，其中頁面的基本結構正常加載，表和列表使用AJAX加載，並提供一個鏈接（對於使用javascript的用戶將隱藏）來重新加載頁面所有數據都存在。
這是一個很好的問題，我也在努力掙扎。我目前的擔憂僅限於我們控制客戶端和服務器的Intranet情況。在這些情況下，我的感覺是最好採取中間立場。我認爲其他開發人員可以查看.aspx並理解頁面的要點，這一點很重要。
例如，如果需要顯示一個數據表，然後將其作爲json發送出去，然後在客戶端上對其進行模板化（這不會很好地表現出來），將其作爲普通的ASP.NET數據網格發送html片段。坐在.aspx上的datagrid至少顯示了顯示錶格數據的意圖。而且這樣做也許更容易。
現在，假設你想顯示一個真正的花哨的數據網格，這將很難做到只使用ASP.NET。我仍然會把它作爲一個簡單的數據網格發送，因爲jQuery可以在客戶端上更容易地切割和切割它，而不是ASP.NET可能返回到服務器上。可能這也會節省一些帶寬。 （哦，我總是關閉所有ViewState！）我嘗試讓ASP。NET做的語義，以及它擅長的簡單的東西，並讓jQuery做剩下的事情。
在實踐中事情變得更加複雜和模糊。作爲一名模型視圖演示者，我開始將視圖和演示者視爲客戶端。 .aspx頁面只是一個顯示頁面要點的模板。代碼隱藏（.aspx.cs）只不過是委託給模型的一個薄層。
雖然我對這個架構的結果感到非常滿意，但我仍然對此感到隱約不舒服，主要是因爲我無法用可靠的舊NUnit單元測試演示者，還因爲jQuery和JavaScript如此強大這就像玩炸藥一樣。
通常的架構專家都是沉默的，這是全新的。我百分之百地確信，很多人已經在30年前就已經研究過這種情況了，而且遲早都會在你看的所有地方詳細討論這一點。但這是一個非常有趣的情況，我希望更多的人能夠投入2美分。馬丁福勒在哪裏？ Scott Bellware？鮑勃叔叔？
Mike
我覺得在客戶端需要JS很舒服。這將用於Web應用程序。 – 2009-02-12 20:59:57