2009-10-25 22 views
8

我正在學習ASP.NET。我買了一些關於這個主題的書。 所有這些都建議使用數據源控件,比如ObjectDataSource/SqlDataSource等是要走的路。現在,我絕對不是這方面的專家,實際上遠非如此。但我有強烈的感覺,那就是玩具工具。我很難相信這些類將用於現實世界的企業級應用程序。我對嗎?或者這些類實際上在大型Web應用程序中有一席之地嗎?在ASP.NET中使用數據源控件真的很專業嗎?

感謝, 阿維

+0

嗯,我看到意見不一。 我想我會試試看,只是讓我有第一印象,如果沒有別的。 我有一種感覺,我最終會放棄它。從服務器端開發背景來看,我發現很難在UI層中添加任何邏輯,即使它只是「聲明式」。謝謝你們:) – 2009-10-26 08:08:15

回答

10

這些控件使用它們不理解他們已經獲得了壞名聲由於不熟練的開發人員和專業開發人員看不起他們作爲一個結果。我可以給你的最好的建議是,專業人員會使用最合適的工具,並且完成工作而不會妨礙工作。如果這些工具爲你完成這項工作,那麼你應該使用它們,不要讓人們爲此付出代價。

1

如果查詢很簡單,它們對於填充綁定控件非常好,就像下拉列表類別一樣。他們對於自定義搜索或類似搜索非常痛苦。根據具體情況評估您的方法。

0

就我個人而言,我更喜歡自己的東西。運行存儲過程來檢索數據並將其分配給數據輸入控件而不使用數據綁定非常簡單。抓取修改後的數據並根據需要添加,更新或刪除也很容易。數據源類添加了我認爲是不必要的額外層。如果他們比我做得更簡單,我可能會給他們一個鏡頭,但他們對我來說似乎很複雜。而且,即使我沒有任何基準數據來證明這一點,但它似乎必須效率較低。

1

完全同意 - 在單元測試中,DDD,TDD的現代世界與HTML,潛在的商業邏輯,等,等的數據庫連接的東西混合是一個非常糟糕的主意,等

會有在適當的情況下(也許是最簡單的報告任務需要快速完成,模型),但通常避免它們。

2

我想人們可能會爭辯說,使用ObjectDataSource是合理的,假設它實際上是在與真正的中間層對象交談。特別是如果開發者擴展ODS來與他們的中級玩家一起玩。

其他人會在我的店裏弄傷你的手指(第二次進攻)。

2

您需要了解的關於ASP.NET的第一件事是,與服務器控件相關的所有內容以及webforms範例通常不會像Response.Write()那樣好。 webforms的整個想法是儘快讓你從A點到B點。所以,在你選擇webforms之前,你應該問問自己,這是我的應用程序的最佳框架嗎?對於高流量的網站,和/或如果你非常關心設計模式,我會毫無疑問地選擇MVC。

現在,如果您選擇webforms,那麼我強烈建議您使用數據源控件。它會讓你的生活更輕鬆。我不知道你如何定義企業級應用程序,但數據源控件可以實現偉大的事情。我建議你看看LinqDataSource,EntityDataSource,新的DomainDataSource,新的QueryExtender以及它們如何與任何IQueryable源一起工作。

3

我同意懷亞特的看法,並認爲我應該增加一點信息。所有數據源對象(ObjectDataSource除外)的問題是您無法將應用程序分成多個邏輯層(即UI,業務邏輯,數據訪問)。您將所有的數據訪問代碼放入您的用戶界面中,從項目的架構視圖來看,這非常糟糕。

+0

謝謝你的回覆賈森。 我只是在評論中提出了一些問題。 你已經提到,除了ObjectDataSource之外,所有數據源控件在多層應用程序中確實可能存在問題。你是說這個特定的控件確實可以在多層應用程序中使用嗎?如果可以的話,是否建議在這種情況下使用它? 感謝您的時間 – 2009-10-26 17:21:42

+0

ObjectDataSource可用於多層應用程序,因爲您可以將它「掛接」到業務層中的對象。它絕對可以用作通過多層應用程序訪問綁定數據源的所有功能的方式。 – 2009-10-26 17:50:02

1

數據源控件將代碼直接放入表單中的陳述不一定是正確的陳述。通常,您有一個控制器類,並將數據源控件綁定到控制器的方法。

你仍然有你的中間層和其他任何東西。正如一張海報所說,通常它是經驗豐富的開發人員,他們破壞了爲什麼這些控制器很有價值。他們處理頁面的所有管道,並且在UI和中間層(控制器)之間仍然存在分離。

但是這也取決於你是否更喜歡與數據集相反的域對象的程序員。