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个。我确信社区将有更多关于这些开发实践的说法，但是这是我对这一切的看法。谢谢，祝你好运。