Question: We normally use abstract function/Interfaces in our projects. Why it is really needed? Why can't we just go for Business logic Layer, Data Access Layer and Presentation Layer only

**Function in Presentation Layer:**

```
abc();

```

---

**Function in Business Logic Layer:**

```
 public void abc()
    {
      //Preparing the list
    }

```

---

**Function in Data Access Layer:**

```
public abstract void abc();

```

---

**Function in Data Access SQLServer Layer:**

```
 public override void abc()
    {
       //Connection with database
    }

```

---

**Question is: Why is the Data Access Layer required ?**

Answer: 
The abstract class or interface is not really a separate layer - it should be part of your business logic layer and it defines the interface that the actual data access layer (SQL data repository, for example) needs to implement to provide the data access service to your business layer.

Without this interface your business layer would be directly dependent on the SQL layer, while the interface removes this dependency: You put the abstract class or the interface into the business logic layer. Then the SQL layer (a separate assembly, for example) implements the abstract class/interface. This way the SQL layer is dependent on the business layer, not the other way around. 

The result is a flexible app with an independent business layer that can work with multiple data repositories - all it needs is a layer that implements the interface the business layer defines. And it is not really only about data repositories - your business layer shouldn't be dependent on the context (asp.net vs. console app vs. service etc.), it shouldn't be dependent on the user interface classes, modules interfacing with your business app, etc.
The abstraction helps create functionality, be it through a base class, an interface, or composition which, when used properly, does wonders for maintenance, readability, and reusability of code.

In regards to the code posted in the question, the code marked "Data Access Layer" acts as a common abstraction for the business layer to use. By doing so, the specific implementations of the the DAL (such as what's under "Data Access SQLServer Layer" in the sample) are decoupled from the business layer. Now you can make implementations of the DAL that access different databases, or perhaps automatically feed data for testing, etc.

The repository pattern is a fantastic example of this at work in a DAL (example is simplified):

```
public interface IProductRepository
{
    Product Get(int id);
    ...
}

public class SqlProductRepository : IProductRepository
{

    public Product Get(int id) { ... }
    ...
}

public class MockProductRepository : IProductRepository
{
    private IDictionary<int, Product> _products = new Dictionary<int, Product>()
    {
        { 1, new Product() { Name = "MyItem" } }
    };

    public Product Get(int id) { return _products[id]; }
    ...
}

public class AwesomeBusinessLogic
{
    private IProductRepository _repository;

    public AwesomeBusinessLogic(IProductRepository repository)
    {
        _repository = repository;
    }

    public Product GetOneProduct()
    {
        return _repository.GetProduct(1);
    }
}

```

Even though this example uses interfaces, the same applies to the use of base classes. The beauty is that now I can feed either `SqlProductRepository` or `MockProductRepository` into `AwesomeBusinessLogic` and **not have to change anything about `AwesomeBusinessLogic`**. If another case comes along, all that's needed is a new implementation of `IProductRepository` and `AwesomeBusinessLogic` will still handle it without change because it only accesses the repository through the interface.