爲什麼要創建類來表示Web應用程序中的數據？

Question

在過去，我通常使用類來表示我設計和構建的應用程序中的數據。但是在網絡應用程序中，這似乎並不需要/不適用，因爲數據存儲在數據庫中，像DataSet這樣的工具對於檢索和保存數據非常有用。

我目前正與ASP.NET的工作，和數據綁定控件（如GridView）似乎要綁定到SqlDataSource，ObjectDataSource，DataView等，所以，給出一個靜態MyDB類拉動DataSet出來的數據庫中，我的面向數據的頁面代碼往往本質上是這樣的：

DataSet employeeData = MyDB.GetData(); 
DataView dvEmpData = new DataView(employeeData); 
grdData.DataSource = dvEmpData; 
grdData.DataBind(); 

因此我一般不具有數據類對應於我的數據庫架構。但是像POCO這樣的新開發和EF框架支持創建和使用這些類。這有什麼好處？我的想法是：

• 編譯時錯誤，其中拼寫錯誤，否則直到運行時纔會被忽視。 employeeData[0].Rows[i]["Name"]是不一樣好employees[i].Name其中employees是IEnumerable<Employee>
• 在C＃3和以後，使用LINQ和涼爽擴展方法上IEnumerable<T>過濾數據集合靈活而無需創建的能力/改變在存儲過程或查詢我需要做的每個聚合/選擇的數據庫。
• 源代碼在SCM下比在數據庫內容更容易保留，這意味着在源代碼中保留更多的邏輯更好。
• 像我這樣的人誰學會CS做本地應用程序更舒適:-)

在另一方面，把它們在屏幕上之前，將數據轉換成.NET類是需要計算時間的工序，並不是絕對必要的。而且我有一種感覺，GridView和它的同胞會優先於而與DataView綁定。另外，數據庫在查詢和彙總數據方面要比LINQ更快。

POCO認可的方法背後的推理是什麼？我在這裏覆蓋它，還是我錯過了什麼？

Answer 1

要簡明地回答您的具體問題：

利用業務對象可以讓你的數據在存儲的效率比在SQL或多個位置的一個特設的方式執行的邏輯。

• 示例：當頁面名稱更改時需要設置URLRewrite？其中一箇中心位置顯然是理想的。

但是...

您可以通過使用LINQ to SQL或排除大部分底片，在更復雜的情況，其他的ORM的，如Entity Framework或nHibernate。

閱讀Part 1和Part 2關於LINQ to SQL的一些啓發。

• 使用LINQ to SQL，您可以獲得沒有缺點（您提到的）的好處以及一些額外的好處。

可是...

在情況下，您並不需要那種不平凡的邏輯 - 你不妨使用SQLDataSource和直接綁定到一個GridView;然而，LINQ to SQL非常簡單，許多人甚至在最簡單的情況下都喜歡它。