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: 
Generally, if you use interfaces in your code, then you will gain code manuverability in the form of Dependency Injection. 

This will help you replace parts of your implementation in certain situations for example providing Mock objects during Unit Testing.
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.