3

ASP.NET MVC プロジェクトで 3 層アーキテクチャとリポジトリ パターンを使用しようとしています。しかし、場合によっては、3 層アーキテクチャーとリポジトリー・パターンがほとんど同じに見えます。そこで、より明確にするために次のことを調べてみました。

リポジトリ パターン

N 層アーキテクチャ

その後、実装のために次のコードに入りました。より効率的な方法で実装を改善するためのアドバイスを期待しています。

モデル- 部門クラス:

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 クラス:

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セクションを離れます。これが続行する正しい方法であるかどうかを確認し、お知らせください。ありがとう。

追記：こんな質問ですみません。私は実際にこれら 2 つのことを混ぜ合わせており、コード サンプルを使用して専門家からのアドバイスを期待しています。リンクを投稿しないでください。私はすでにいくつかを見てきました。

4

1 に答える 1

5

N 層とリポジトリ パターンは矛盾していません。実際、それらは互いに何の関係もありません。N 層は、アプリケーションをレイヤーで構築する必要があるという単なる哲学です。それは本質的にモジュール化に関するものです。リポジトリ パターンは抽象化に関するものです。つまり、アプリケーション コードから SQL クエリを抽象化します。同じアプリケーションで両方を行うことができます。

ただし、リポジトリ パターンに関しては多くの論争があります。それはORMよりも前のものであり、ORMで冗長になるという強い議論があります。たとえば、Entity Framework では、DbContextが作業単位であり、それぞれDbSetがリポジトリです。この時点で利用する必要があるのは、実際には戦略パターンです。データ アクセスを表すインターフェイスが必要であり、後で実装 (ORM) を使用して入力します。ただし、それは実際にはここでのコードにはあまり影響しないため、主にセマンティクスです。おそらく実際には「リポジトリ」は必要ないことに注意してください。また、エンティティごとにこれらの実装のいずれかを使用するかのようにアプリを構築するべきではありません。

于 2016-11-10T17:08:38.097 に答える