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.
All of the previous answers may explain the needs of abstract layers, but I still want to add some of my thoughts.

Let's say that in our project we just have one implementation of a service in each layer. For instance, I have a contact DAL and a contact BLL service , and we could do something like this

```
namespace Stackoverflow
{
    public class ContactDbService
    {
        public Contact GetContactByID(Guid contactID)
        {
            //Fetch a contact from DB
        }
    }
}

```

Contact BLL service:

```
namespace Stackoverflow
{
    public class ContactBLLService
    {
        private ContactDbService _dbService;
        public ContactBLLService()
        {
            _dbService = new ContactDbService();
        }

        public bool CheckValidContact(Guid contactID)
        {
            var contact = _dbService.GetContactByID(contactID);

            return contact.Age > 50;

        }
    }
}

```

without defining interfaces/ abstract classes.

If we do like that, there would be some obvious drawbacks.

1. **Code communication:**
Imagine that if your project involves, your services may have many different methods, how could a maintainer (apart from you) know what your services do? Will he have to read your entire service in order to fix a small bug like InvalidCastOperation?
By looking at the interface, people will have the immediate knowledge of the capabilities of the service(at least).
2. **Unit testing**

You could test your logic using a fake/mock service to detect bugs in advance as well as prevent regression bugs from happening later.
3. **Easier to change:**

By referencing only by interfaces/ abstract classes in other classes, you could easily replace those interface implementations later without too many efforts of work.