我已經用ASP構建了幾個數據庫驅動的網站，我試圖將基本功能遷移到ASP.NET體系結構。在ASP.NET中實現ASP策略
我希望我的導航樹中的每個鏈接都對應不同的函數，它將引導用戶完成各種請求並提供順序數據庫驅動的響應和可能的後續問題。我通常使用查詢字符串在SSI文件中執行代碼的不同部分，從而在ASP中執行此操作。我的導航樹中的每個鏈接基本上都調用一個不同的SSI文件。
在ASP.NET中，我認爲我在Web表單基礎知識，數據綁定，站點導航工具和母版頁上有相當好的處理能力，但是我在整體設計圖中遇到了問題。
我想讓每個鏈接都將用戶重定向到不同的頁面嗎？我的理解是，ASP.NET在維護狀態信息方面要好得多，所以我不應該依賴查詢字符串來將值傳遞給SSI文件，以執行每個任務的順序部分。
我應該使用BLL和DAL來執行此操作和/或存儲過程和託管代碼嗎？或者我可以更簡單地使用ASP.NET網頁來做這種事情，而不是使用Web表單？
反饋將包括參考文章和/或Web示例將不勝感激。謝謝！
你不一定要放棄你的整個思維方式，並採取ASP.NET Web窗體。
自從2001年問世以來，我一直在使用ASP.NET Web Forms製作網站。但是我認爲ASP.NET MVC對您來說會是一個更簡單的過渡。我的意思是，有些事情在MVC中比在Web Forms中更困難。但總體而言，MVC將推廣更多的網絡友好型做法，而這正是我現在更喜歡的做法。
例如，Web窗體中的回發和查看狀態的整個想法確實使許多事情變得更容易。但他們也有一個傷害搜索引擎優化和打破後退按鈕的問題。 MVC不依賴任何這些，並且通過表單帖子，重定向和URL的處理方式來更好地改進用戶體驗。
我寫過一篇文章，一段時間回來比較VS MVC Web窗體... http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
+1。就我個人而言，我不是MVC的粉絲，但那是我自己的問題。我是那些真正喜歡WebForms模型的bozos之一。 ;-)但是我認爲你的建議很好，因爲MVC確實看起來更像經典的ASP，而且我認爲這也將是一個更簡單的過渡。 – David
@DavidStratton - 過去幾周我一直在MVC中構建一個由300多個問題組成的問卷。在過去，我會在Web窗體中構建這種類似於形式的東西。但是這是MVC中現有系統的一部分。無論如何，有些事情更加困難。但是一旦我走了，這並不算太壞。是的，我確實認爲來自傳統ASP的人會更容易適應MVC。 –
我無法提交答覆。請在下面看到新的回覆...... – Brubeck
基於我所看到的，它看起來就像你在多個ASP頁得到了嚮導式導航，和你想要在ASP.NET（WebForms而非MVC）站點中使用嚮導式導航。
如果我誤解了這一點，我會很樂意刪除這個答案。
我推薦了Wizard control，（Video demos available all over the place），這將在一個頁面上提供這樣的接口，減少了很多的複雜性。沒有必要跟蹤跨頁面的變量 - 這些都在一個頁面中，因此始終可以訪問。
嚮導頁面傾向於擁有大量的代碼和標記，但是權衡是所有嚮導功能都在同一個步驟中，而不是分散在各個文件中，並且在每個步驟中很明顯會發生什麼。採用多文件方法時，維護開發人員需要跟蹤哪些頁面帖子到哪個頁面，並花費更多時間來理解設計。
關於MVC vs Web Forms的文章相當有趣，雖然在看了一些培訓視頻之後，我覺得編碼和ASP有很大不同。 （我也看到大多數例子都涉及到C＃，儘管我已經看到了一些VB，這是首選，因爲我已經在很短的時間內學習了很多新東西。）另外，我想知道MVC是否會讓我使用驗證工具，這將是這個項目的一個不同方面非常必要的，它涉及幾種不同的和相當長的形式。鑑於我已經投入了相當多的時間學習ASP.NET，我想知道是否應該多走一公里（或兩步）並學習如何創建業務對象（BLL）和數據層（DAL ）。
MVC 3驗證在這裏總結得相當不錯... http://www.codeproject.com/Articles/249452/ASP-NET-MVC3-Validation-Basic –
讓我通過一個非常簡單的高級概述來檢查我的理解......實質上，您有一個類似嚮導的接口來實現ASP.NET嗎？ （根據以前的問題逐步處理各種要求和不同的後續問題是我從哪裏得到的）這是正確的嗎？ – David
請參閱下面的評論。我是新來的stackoverflow和無法響應... – Brubeck