Three-Tier Architecture Vs Repository Pattern

Question

I am trying to use three-tier architecture and repository pattern in ASP.NET MVC project. But in some cases, the three-tier architecture and repository pattern look almost same. So I tried to study the followings to make it more clear:

The Repository Pattern

N-Tier Architecture

After that, I've come into the following code for implementation and would expect some advices to improve the implementation in a more efficient way:

Models - Department class:

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

Interfaces - IRepository Interface:

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

DAL - DepartmentGateway Class:

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;
      }
   }
}

I am leaving the UI section. I am trying to assure if this is the right way to proceed and let me know. Thanks.

Note: I apology to ask this question. I am actually mixing these two things and would expect some advices from the experts with code samples. Please don't post any links. I've already seen some.

Hello @Div! For the time being, no. It's in testing mode and will migrate later to ORM. — AT-2017, Nov 10 '16 at 16:47

score 6 · Accepted Answer · answered Nov 10 '16 at 17:08

6

N-Tier and the repository pattern are not contradictory. They really have nothing to do with each other, in fact. N-Tier is just a philosophy that your application should be built in layers. It's essentially about modularization. The repository pattern is about abstraction, namely abstracting SQL queries from application code. You can very well do both in the same application.

However, there's a lot of contention around the repository pattern. It predates ORMs and there's a strong argument to be made it's redundant with an ORM. With Entity Framework, for example, the DbContext is your unit of work, and each DbSet is a repository. What you should be utilizing here at this point is really a strategy pattern. You need some interface that represents your data access, and you're going to fill it in later with an implementation (your ORM). That really doesn't affect your code here much, though, so its mostly semantics. Just bear in mind that you probably don't actually want a "repository", and you definitely shouldn't build your app as if you're going to have one of these implementations per entity or such.

answered Nov 10 '16 at 17:08

Chris Pratt

232,153
36
385
444

So what you meant is to use ORM in order to implement the repository pattern? Strategy pattern seems like a new one. Never mind. Last question - Does my above written code make any difference or perfection for the repository pattern? Just trying to make sure. – AT-2017 Nov 10 '16 at 17:31
No. I'm saying an ORM satisfies the repository pattern. The strategy pattern is just an abstraction that allows you sub-in different "strategies" for a piece of functionality. In other words, you utilize an interface and code against that interface. Later you can inject an implementation of that interface. For example, in this scenario, you could have an Entity Framework implementation, a Web Api implementation, etc. All your application knows is that it's calling a method on an interface. In the implementation you decide how you're going to retrieve the data. – Chris Pratt Nov 10 '16 at 18:02
It's actually a little backwards to begin your application by *not* using an ORM though. Ironically, you should probably have a unit of work and one or more repositories *based on the way you're currently getting the data*. That's because you would want all this logic encapsulated somewhere out side of your application code. However, as soon as you introduce an ORM, that's all then unnecessary. – Chris Pratt Nov 10 '16 at 18:04
I'll try to migrate to ORM (EF) asap as it seems very important. Thanks for your time to go through it. So you are saying my above written code is almost semantic to the repository pattern but would be better with ORM. – AT-2017 Nov 11 '16 at 06:13

Three-Tier Architecture Vs Repository Pattern

1 Answers1