ASP.NET MVC 4項目沒有任何ORM

Question

我想使用ASP.NET MVC沒有EF和可能不LINQ。首先，我在VS2010中創建了基本的ASP.net mvc模板上的一個表/模型/控制器/視圖（僅實現了索引頁和索引方法）。我目前正在嘗試/錯誤，因爲網絡上的所有教程都基於EF，並且我擁有嵌入式c背景。

我的問題是：

• 體系結構是否正確？

• 只見庫模式在一些開源項目使用，如nearforums。它的優點是什麼？它如何適應這個問題，是否取代DAL？

• 我應該通過數據表，以查看或對象表示的數據表？

• 我可以傳遞比一個模型剃刀頁嗎？我如何列出2個不同的表格？

• 是更好地把所有DAL代碼在一個文件？

DAL：

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Web; 
using System.Data; 
using System.Configuration; 
using MySql.Data.MySqlClient; 

namespace MvcApplication1.Models 
{ 
    public class DAL 
    { 
    public DAL() 
    { } 
    public DataTable getDataTable(string tableName) 
    { 
     using (MySqlConnection conn = new MySqlConnection(ConfigurationManager.ConnectionStrings["MySQLConn"].ConnectionString)) 
     { 
     using (MySqlCommand command = conn.CreateCommand()) 
     { 
      command.CommandText = "select * from " + tableName; 
      command.CommandType = CommandType.Text; 

      conn.Open(); 

      var table = new DataTable(); 
      table.Load(command.ExecuteReader()); 

      return table; 
     } 
     } 
    } 
    } 
} 

，它表示代碼產品表Product.cs類：

namespace MvcApplication1.Models 
{ 
    public class Product 
    { 
     public int ProductId { get; set; } 
     public string Name { get; set; } 
     public string Producer { get; set; } 
     public int UnitPrice { get; set; } 
    } 
} 

ProductController.cs

namespace MvcApplication1.Controllers 
{ 
    public class ProductController : Controller 
    { 
     // 
     // GET: /Product/ 
     DAL dal = new DAL(); 
     public ActionResult Index() 
     { 
      DataTable dt = dal.getDataTable("Product"); 
      Product[] products = new Product[dt.Rows.Count]; 
      for (int i = 0; i < dt.Rows.Count; i++) 
      { 
      products[i] = new Product(); 
      products[i].ProductId = (int)dt.Rows[i]["ProductId"]; 
      products[i].Name = (string)dt.Rows[i]["Name"]; 
      products[i].Producer = (string)dt.Rows[i]["Producer"]; 
      products[i].UnitPrice = Decimal.ToInt32((decimal)dt.Rows[i]["UnitPrice"]); 
      } 

      return View(products); 
     } 
........ 
........ 
} 

Index.cshtml：

@model IEnumerable<MvcApplication1.Models.Product> 
@{ 
    ViewBag.Title = "Index"; 
} 

<h2>Index</h2> 
@foreach (var item in Model) 
{ 
    <tr> 
     <td> 
      @Html.DisplayFor(modelItem => item.ProductId) 
     </td> 
     <td> 
      @Html.DisplayFor(modelItem => item.Name) 
     </td> 
     <td> 
      @Html.DisplayFor(modelItem => item.Producer) 
     </td> 
     <td> 
      @Html.DisplayFor(modelItem => item.UnitPrice) 
     </td> 
     <td> 
      @Html.ActionLink("Edit", "Edit", new { id=item.ProductId }) | 
      @Html.ActionLink("Details", "Details", new { id=item.ProductId }) | 
      @Html.ActionLink("Delete", "Delete", new { id=item.ProductId }) 
     </td> 
     <br> 
    </tr> 
} 

Answer 1

只見庫模式在一些開源項目使用，如nearforums。它的優點是什麼？它如何適應這個問題，是否取代DAL？

庫模式的好處是，它可以讓你切換出數據訪問邏輯/ ORM。例如，如果你想從實體框架轉換到NHibernate的，你只要更新註冊你內心的IoC容器和像變魔術一樣你的代碼使用NHibernate 0知識，你曾經做出的開關。它允許你的代碼不知道底層的持久性框架。據瞭解，結果代碼來自文件，Web服務調用或內存列表。如果您必須從另一個組件進行相同的查詢，您還可以重用。另一個收益是單元測試。使用您當前的實現，您不能對您的控制器進行單元測試，因爲它每次都會直接連接到數據庫，因此通過定義將其作爲集成測試。你一定會想要利用一個ORM，否則你會一遍又一遍地寫相同的代碼，直到它讓你哭。設置/拆除連接，將所有基元類型轉換爲本機.NET類型等。處理本機ADO.NET是當今時代的事情。讓您的生活更輕鬆並使用ORM。同時，以強大的力量來承擔巨大的責任。如果您不驗證正在針對數據庫生成和執行的查詢，ORM可能是一場噩夢。如果使用不當，他們會產生性能問題。您可以在大多數查詢中利用LINQ，但有時您必須獲得髒時髦的本機並使用原始SQL。你的ORM仍然能夠處理這兩種情況。

我應該傳遞數據表來查看錶示數據表的對象嗎？

你當然不想傳遞數據表。您想要將視圖模型或實體傳遞給您的視圖。該視圖應該對數據庫一無所知。你所要做的就是給它提供數據，並且它永遠不知道數據的來源。如果你使用的是類似NHibernate的東西，那麼你需要小心地將實體直接傳遞給你的視圖，因爲你遇到了與延遲加載和N + 1查詢相關的問題。查看模型通常會減少實體的版本。例如，如果您有一個擁有4個屬性的實體，但視圖只需要消耗這些屬性的2/4，那麼您將創建一個具有2個屬性的單獨視圖模型，並使用像Automapper這樣的映射庫將映射從您的實體映射到視圖模型。

我可以將多個模型傳遞給剃鬚刀頁嗎？我如何列出2個不同的表格？

這很簡單。您創建頂級對象，併爲其指定2個屬性來表示要訪問的實體。

public class MyViewModel 
{ 
    public Entity1 FirstObject { get; set; } 

    public Entity2 SecondObject { get; set; } 
} 

然後你會成爲一個強類型的視圖，並使用你張貼在你的問題你的剃鬚刀視圖中使用強類型的視圖助手渲染FirstObject和SecondObject。 @ Html.TextBoxFor（）等

最後，您的控制器將接受MyViewModel作爲參數，並基於您的視圖中呈現的表單輸入填充FirstObject和SecondObject。

將所有DAL代碼放在一個文件中會更好嗎？

您想將相關的DAL代碼放在同一個文件中。事物通常由表格繪製出來，但這一切都取決於對象之間的關係（例如，你的聚合根是什麼）。你不想做的是盲目地爲每個表實現一個存儲庫。你最終會遇到一個真正的過程性和貧乏的數據模型，它會通過對數據庫的多次調用將對象圖和關係拼接在一起。我建議尋找域驅動設計來獲得一個關於如何解決這個問題的好主意。

我剛剛在這裏表面劃痕。如果你想正確地做這件事，你基本上需要選擇最新的模式和實踐。這是一個不同的運動。不像歷史悠久的單片代碼背後的文件，視圖狀態和DataGrid控件。有一些很好的書有像：

布朗菲爾德應用開發 領域驅動設計（埃裏克·埃文斯） 清潔編碼器（羅伯特·ç馬丁） 重構：改善既有代碼的設計（馬丁·福勒） 企業模式應用程序體系結構（Martin Fowler）

我並不是說逐字閱讀所有這些書，但我強烈建議第2個。我確信社區將有更多關於這些開發實踐的說法，但是這是我對這一切的看法。謝謝，祝你好運。