三层架构与仓储模式

Question

我打算在ASP.NET MVC项目中使用三层架构和仓储模式，但在某些情况下，这两者看起来几乎相同。因此，我尝试研究以下内容以使其更加清晰: 仓储库模式 N层架构 之后，我查看了以下代码实现，并期望得到一些建议以更高效的方式改进实现: Model - Department类:

public class Department
{
   public int DepartmentID { get; set; }
   public string Code { get; set; }
   public string DepartmentName { get; set; }
}

接口 - IRepository 接口：

public interface IRepository
{
   public int Add(Student aStudent); //For Adding Students
   public int Add(Department aDepartment);  //For Adding Departments
} 

DAL - DepartmentGateway 类：

public class DepartmentGateway : IRepository
{
   /****Repository Pattern - Starts****/
   Gateway aGateway = new Gateway();
   public int Add(Department aDepartment)
   {
      aGateway.Query = "INSERT INTO Departments (Code, Name) VALUES (@Code, @Name)";

      aGateway.Command = new SqlCommand(aGateway.Query, aGateway.Connection);

      aGateway.Connection.Open();

      aGateway.Command.Parameters.Clear();
      aGateway.Command.Parameters.Add("Code", SqlDbType.NVarChar);
      aGateway.Command.Parameters["Code"].Value = aDepartment.Code;
      aGateway.Command.Parameters.Add("Name", SqlDbType.NVarChar);
      aGateway.Command.Parameters["Name"].Value = aDepartment.DepartmentName;

      int rowAffected = aGateway.Command.ExecuteNonQuery();

      aGateway.Connection.Close();

      return rowAffected;
   }
   /****Repository Pattern - Ends****/
}

BLL - DepartmentManager Class:

public class DepartmentManager
{
   DepartmentGateway aDepartmentGateway = new DepartmentGateway();

   public int Add(Department aDepartment)
   {
      int affect = aDepartmentGateway.Add(aDepartment);

      if (affect > 0)
      {
         return 1;
      }
      else
      {
         return 0;
      }
   }
}

我正在离开UI部分。我想确保这是正确的操作方式，请告诉我。谢谢。

注：很抱歉要问这个问题。我实际上混淆了这两件事，并希望从专家那里得到一些带有代码示例的建议。请不要发布任何链接，我已经看过一些了。

- AT-2017

---

你没有使用ORM吗？ - Divyang Desai

你好 @Div！目前还没有。它正在测试模式下，并将稍后迁移到ORM。 - AT-2017

Answer 1

N-Tier和存储库模式并不矛盾。实际上，它们之间并没有任何关系。N-Tier只是一种哲学，即您的应用程序应该构建在层之上，它实质上是关于模块化的。存储库模式是关于抽象的，即将SQL查询与应用程序代码分离。你可以在同一个应用程序中同时完成这两个方面。

然而，存储库模式存在很多争议。它早于ORM，并且有很强的理由认为它与ORM重复了。例如，在Entity Framework中，DbContext是您的工作单元，每个DbSet都是一个存储库。在这里，您应该使用策略模式。您需要一些代表数据访问的接口，稍后会用实现(ORM)填充它。但这实际上对您的代码影响不大，所以它主要是一种语义。只需记住，您可能实际上不需要"存储库"，绝对不应该按实体或类似实现构建应用程序。

- Chris Pratt

---

那么你的意思是使用ORM来实现仓储模式？策略模式似乎是一个新的模式。没关系。最后一个问题 - 我上面写的代码对于仓储模式有任何不同或完善吗？只是想确认一下。 - AT-2017

不，我是说ORM满足存储库模式。策略模式只是一种抽象，允许您为功能的某个部分替换不同的“策略”。换句话说，您利用接口编写代码。稍后，您可以注入该接口的实现。例如，在这种情况下，您可以拥有Entity Framework实现、Web Api实现等。您的应用程序知道的只是它正在调用接口的方法。在实现中，您决定如何检索数据。 - Chris Pratt

实际上，通过不使用ORM来开始您的应用程序有点反向。具有讽刺意味的是，根据您当前获取数据的方式，您可能应该拥有一个工作单元和一个或多个存储库。这是因为您希望将所有这些逻辑封装在应用程序代码之外的某个地方。但是，一旦引入ORM，所有这些都是不必要的。 - Chris Pratt

我会尽快尝试迁移到ORM（EF），因为它似乎非常重要。感谢您花时间阅读。所以你的上述代码几乎符合存储库模式，但使用ORM会更好。 - AT-2017