SqlDataSource vs ObjectDataSource

Question

如果網頁需要一些數據，爲什麼不只是讓SQLDataSource調用存儲過程呢？爲什麼使用ObjectDataSource調用業務對象，然後調用存儲過程？我知道在.net框架上構建的其他應用程序（可以說是桌面應用程序）可以訪問業務對象，但是如果應用程序始終只是一個Web應用程序，該怎麼辦？

更清楚：

一個何時應該使用SqlDataSource或ObjectDataSource？

如何激發選擇？

Answer 1

僅僅是一個SQLDataSource是完全有效的，如果它只是一個演示，原型或快速入侵。它很快，很容易，它只是起作用，併爲您提供所需的結果。但是，如果長期設計和構建應用程序，並預期事物（需求，客戶願望，最終數據庫模式）可能會發生變化，那麼引入適當的「業務「層 - 將業務對象建模爲對象，然後提供從底層數據庫到這些業務對象的映射。正如俗話所說 - 你可以通過一層間接（或抽象）的方式解決計算機科學中的任何問題 - 這裏同樣適用。

確定：你可以直接進入數據庫，當然，首先和第一次迭代，這可能（或可能）是最快的方法。但從長遠來看，當應用程序構建成可持續時，它通常是一種快速方式 - 維護成本，維護成本，根據您和您的客戶需求進行更改所需的成本和工作量將會迅速增長，就努力而言，快速解決方案看起來不再那麼棒。

所以總結一下我的觀點：是的，最初，使用直接的SQL數據源可能會更快更容易 - 所以在重要的一點時使用它：爲快速演示完成任務，概念樣式app。但從長遠來看，當您查看應用程序的生命週期時，通常值得投入更多（設計和編碼）工作來添加這個抽象層，以便您的網頁不直接依賴於底下的數據庫。

馬克

Answer 2

如果您在項目中使用了業務層，那麼ObjectDataSource是自然選擇。這很適合許多ORM，並且其中許多提供了額外的好處（驗證，撤消等）。它還允許您訪問業務對象上的任何其他屬性&方法 - 而不僅僅是直接的SQL字段。這可以在綁定時真正實現 - 因爲它允許您只綁定標記中的屬性，而不必編寫大量代碼。

如果你要走這條路線，混合SQLDataSource和ObjectDataSource可能會導致下一個開發者混淆你的項目。在這種情況下，我堅持使用ObjectDataSource來實現代碼一致性。

如果您沒有業務層，並且只是直接敲擊SQL，請使用SQLDataSource。我個人的偏好是所有的SQL代碼都應該在業務或數據層中，因爲我幾乎從不使用SQLDataSource。

Answer 3

，如果你能applay業務層的代碼在存儲過程中 的它能夠更好地使用SqlDataSource的

Answer 4

理論上的ObjectDataSource是更好的。但是，這一切都取決於對象模型編寫和記錄的程度。我們外包了一家使用自定義代碼生成器（他們不會提供）的公司來生成所有的圖層。事實證明，這是一場噩夢，甚至可以進行一些小改動，例如添加屬性或更改字段類型。我現在幾乎把他們所做的一切都廢除了，只是使用他們編寫的存儲過程。

我的長期目標是從頭開始使用商業建模工具&代碼生成器重新編寫應用程序。如果您打算使用objectdatasource，我強烈建議您找一個包含靈活代碼生成器的優秀建模工具。