將ASP.NET動態數據用於數據驅動的網站有什麼缺點？

我看了一些關於ASP.NET動態數據的介紹，我注意到這個選項是第一次創建一個數據驅動的網站。我有一個數據庫和幾張表，剛剛創建了一個動態數據應用程序，我的數據庫，以及...我的應用程序有很多很好看的網頁，它們之間的導航和各種CRUD操作3分鐘後完成。將ASP.NET動態數據用於數據驅動的網站有什麼缺點？

好的，嚴重的是，它當然沒有完成。有很多自定義邏輯可供介紹，設計更改以及頁面或關係刪除，我不想在Web應用程序中實際看到它們。

但是現在我想知道ASP.NET動態數據是否至少有一個可行的起點，還是我最好從頭開始創建逐頁？我可以想象，創建一個快速的數據庫維護Web界面可能是有用的，但是對於一個非常自定義的Web應用程序是否有用？修改腳手架最終比從地面建立一切更復雜嗎？

我對您在動態數據方面的經驗或建議非常感興趣！提前致謝！

來源

2010-02-13 Slauma

我從來沒有換我周圍的領先足以讓任何使用了它。起初，我認爲這是微軟對Ruby on Rails的回答，我也在尋找同樣的好處。我不接近有同樣的好處。當我將它與CMS（DotNetNuke，Sharepoint，Drupal等）進行比較時，它看起來確實動力不足。與ASP.NET MVC相比，它似乎從基本的ASP.NET出錯了（MVC正在從ASP.NET中刪除不好的抽象，而DD則添加了更多的抽象）。

就個人而言，我寧願從頭開始在ASP.NET MVC中構建一些東西，儘管我的日常工作是常規的ASP.NET。我還在學習Drupal，因爲我還沒有發現基於ASP.NET的CMSes的甜蜜點。在工作現場你會想要使用其他人都知道的技術。因此，我認爲知道動態數據的限制通常很有用，因爲基本上任何傳統應用程序都不會使用它，並且您不太可能找到具有現有ASP.NET動態數據體驗的團隊。

快速腳手架很漂亮，但在一天結束時，我認爲它不會讓網站的開發更容易。

來源

2010-02-13 20:28:45

是的，缺乏其他開發團隊的經驗是一個重要的觀點！我將此標記爲答案。不幸的是，我不能標出不止一個，儘管所有三個答覆都是有效和有趣的。所以我標記我可能會遵循的建議。至少我發現到目前爲止，動態數據腳手架可以將少量測試數據手動投入到我的數據庫中，至少比在SQL Server Management Studio中添加數據更合適。感謝迄今爲止您在這裏的所有答案！ – Slauma 2010-02-14 13:05:11

我非常喜歡ASP.NET動態數據，因爲它是創建數據驅動應用程序的快速方法。定製並不是一項複雜的任務。

我從頭開始寫這個技術的企業網站 - 它需要appr。 2個月。所以我認爲這是Web應用程序開發的一個很好的起點。

來源

2010-02-13 19:46:31 sashaeve

僅供參考：您是否使用LINQ to SQL或實體框架作爲數據源？我看到這兩個選項可用。當你開始時，你是否比較了它們，並且發現或許它們比動態數據更好或更容易與其他動態數據一起使用？ – Slauma 2010-02-13 19:54:54

我已經使用了LINQ to SQL，因爲一對一的映射對我來說已經足夠了。 – sashaeve 2010-02-13 20:25:50

如果您archetecture類似於ASP.NET動態數據或DotNetNuke或其他一些入門套件，就去學吧，如果

應用是中小型
你沒有嚴格的期限
你正在學習這項技術。

否則，或者當您將熟練掌握特定技術時，您會更喜歡自己從頭開始工作，因爲它爲您提供了更多自由空間來實施創意。

例如，Asp.Net MVC突破的原因之一就是很多.Net開發人員希望自由開發他們正在構建的產品的開發/架構/流和呈現（HTML）。 Asp.Net WebForms確實爲快速開發和模板提供了堅實而廣闊的基礎，但開發人員必須根據架構進行開發。這種自由在MVC下是可用的，開發人員可以利用幾乎所有可用的庫和技能，並採用他們自己的方式。

一個成功的樣本是Stackoverflow.com本身

希望這有助於

來源

2010-02-13 20:08:51

我不怕走更難的路。如果我想實現在動態數據框架中可能不被很好支持的功能，我更害怕去經過一段時間並且隨着應用程序增長而變得更不靈活和更復雜。如果我正確理解你的答案，我將擁有MVC（甚至Webforms？）的更多自由和靈活性。嗯，我對動態數據還是有點懷疑。 – Slauma 2010-02-13 20:53:52

據我所知動態數據框架基於ASP.NET WEBFORMS – 2010-02-13 21:50:25

將ASP.NET動態數據用於數據驅動的網站有什麼缺點？

回答

相關問題