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 easiest way to understand this, imo, is an abstraction over `DataLayer`.

You have set a functions to retrieve a data from `xml` file. But one day your product scales out and `xml` is not enough like a data storage. So you pass to some embeded database: `sqlite`. But one day you need to reuse your library in some enterprise context. So now you need to develop access to `sqlserver`, `oracle`, `webservice`.... In all these changes you will need to change *not only* the code that actually access the data, but the code that actually *consumes* it too. And what about the code that already use for years your first `xml` data access on client and happy with it? How about backcompatibility?

Having the abstraction if not direcly solves most of this problems, but definitely makes scallable your application and more resistant to changes, that, in our world, happen sometimes too frequently.
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.