Three-Tier Architecture Vs Repository Pattern

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.

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.