2016-11-10 8 views
1

ASP.NET MVCプロジェクトで3層アーキテクチャとリポジトリパターンを使用しようとしています。しかし、場合によっては、3層アーキテクチャとリポジトリパターンがほぼ同じに見えます。だから私はそれがより明確にするために以下のことを勉強しようとした。その後3層アーキテクチャとリポジトリパターン

The Repository Pattern

N-Tier Architecture

、私は実装のために、次のコードに来ているといくつかのアドバイスをして実装を改善することを期待しますより効率的な方法:

モデル - 部門のクラス:

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つのことを混在させており、コードサンプルを持つ専門家からのアドバイスを期待しています。リンクを投稿しないでください。私はすでにいくつかを見た。

+0

ORMを使用していませんか? –

+0

こんにちは@Div!当分の間、いいえ。テストモードで、後でORMに移行します。 –

答えて

3

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

しかし、リポジトリパターンの周りには多くの競合があります。それはORMに先行しており、ORMと重複しているという強い議論があります。たとえば、Entity FrameworkではDbContextが作業ユニットになり、各DbSetはリポジトリです。この時点であなたがここで利用すべきものは、実際には戦略パターンです。あなたのデータへのアクセスを表すいくつかのインターフェイスが必要です。そして、実装(ORM)で後でそれを入力します。しかし、それは実際にあなたのコードにはあまり影響を与えません。だから、そのほとんどはセマンティクスです。おそらく実際には "リポジトリ"を望んでおらず、エンティティごとにこれらの実装の1つを持つようにアプリケーションを構築してはいけません。

+0

これは、リポジトリパターンを実装するためにORMを使用することを意味していましたか?戦略パターンは新しいもののように見える。気にしないで。最後の質問 - 私の上に書かれたコードは、リポジトリパターンのために何らかの違いや完全性を作っていますか?ちょうど確かめることを試みる。 –

+0

いいえ、ORMがリポジトリのパターンを満たしていると言います。戦略パターンは、機能性のために異なる「戦略」を継承する抽象化にすぎません。つまり、そのインターフェイスに対してインターフェイスとコードを使用します。後でそのインタフェースのインプリメンテーションをインジェクトすることができます。たとえば、このシナリオでは、Entity Framework実装、Web API実装などがあります。すべてのアプリケーションが知っていることは、インターフェイス上でメソッドを呼び出すことです。実装では、どのようにデータを取得するかを決めます。 –

+0

ORMを使用していない*あなたのアプリケーションを開始するのは実際には少し後ろです。皮肉なことに、現在データを取得している方法に基づいて、作業単位と1つ以上のリポジトリ*を用意する必要があります。なぜなら、このロジックをアプリケーションコードのどこかにカプセル化しておきたいからです。ただし、ORMを導入するとすぐに、そのすべてが不要になります。 –

関連する問題