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.
Abstraction enables you to do refactoring quickly. Think of instead of using SQL server, you decide to use some other provider; if you do not have a data access layer, then you to do a huge refactor because you are calling data access methods directly. But if you have a data access layer, you only write a new data access layer, inheriting from your abstract data access layer and you do not change anything in the business layer.