why do we require interfaces between UI,Business and Data access in C#

问题

I saw in many places whenc# programmers uses 3-tire architecture, they tend to use interfaces between each layer. for example, if the solution is like

SampleUI
Sample.Business.Interface
Sample.Business
Sample.DataAccess.Interface
Sample.DataAccess

Here UI calls the business layer through the interface and business calls the data access in the same fashion. If this approach is to reduce the dependency between the layers, it's already in place with class library without additional use of the interface. The code sample is below,

Sample.Business

public class SampleBusiness{
   ISampleDataAccess dataAccess = Factory.GetInstance<SampleDataAccess>();
   dataAccess.GetSampledata();
}

Sample.DataAccess.Interface

public interface IsampleDataAccess{
   string GetSampleData();
}

Sample.DataAccess

public class SampleDataAccess:ISampleDataAccess{
  public string GetSampleData(){
     returns data;// data from database
  }
}

This inference in between does any great job?
What if I use newSampleDataAccess().SampleData() and remove the complete interface class library?

回答1:

Code Contract

There is one remarkable advantage of using interfaces as part of the design process: It is a contract.

Interfaces are specifications of contracts in the sense that:

If I use (consumes) the interface, I am limiting myself to use what the interface exposes. Well, unless I want to play dirty (reflection, et. al) that is.
If I implement the interface, I am limiting myself to provide what the interface exposes.

Doing things this way has the advantage that it eases dividing work in the development team among layers. It allows the developers of a layer to provide an cough interface cough that the next layer can use to communicate with it... even before such interface has been implemented.

Once they have agreed on the interface. At least on a minimum viable interface. They can start developing the layers in parallel, known that the other team will uphold their part of the contract.

Mocking

A side effect of using interfaces this way, is that it allows to mock the implementation of the component. Which eases the creation of unit tests. This way you can test the implementation of a layer in isolation. So you can distinguish with ease when a layer is failing because it has a defect, and when a layer is failing because the layer below it has a defect.

For projects that are develop by a single individual, or by a group that doesn't bother too much in drawing clear lines to separate work, the ability to mock might be their main motivation to implement interfaces.

Consider for example, if you want to test if your presentation layer can handle paging correctly... but you need to request data to fill those pages. It could be the case that:

The layer below is not ready.
The database does not have data to provide yet.
It is failing and they do not know if the paging code is correct of the defect comes from a point deeper in the code
Etc…

Either way the solution is mocking. In addition, mocking is easier if you have interfaces to mock.

Changing the implementation

If, for whatever reason, some of the developer decides they want to change the implementation their layer, they can do so trusting the contract imposed by the interface. This way, they can swap implementation without having to change the code of the other layers.

What reason?

Perhaps they want to test a new technology. In this case, they will probably create an alternative implementation as an experiment. In addition, they will want to have both versions working so they can test which one works better.

Addendum: Not only for testing both versions, but also to ease rolling back to the main version. Of course, they might accomplish this with source version control. Because of that, I will not consider rolling back as a motivation to use interfaces. Yet, it might be an advantage for anybody not using version control. For anybody not using it... Start using it!
Or perhaps they need to port the code to a different platform, or a different database engine. In this case, they probably do not want to throw away the old code either... for example, if they have clients that run Windows and SQL Server and other that run Linux and Oracle, it makes sense to maintain both versions.

Of course, in either case, you would want to be able to implement those changes by doing the minimum possible work. Therefore, you do not want to change the layer above to target a different implementation. Instead you will probably have some form of factory or inversion of control container, that you can configure to do dependency injection with the implementation you want.

Mitigating change propagation

Of course, they may decide to change the actual interfaces. If the developers working on a layer need something additional on the interface they can add it to the interface (given whatever methodology the team has set up to approve these changes) without going to mess with the code of the classes that the other team is working on. In source version control, this will ease margin changes.

At the end, the purpose of using a layer architecture is separation of concerns. Which implies separation of reason of change... if you need to change the database, your changes should not propagate into code dedicated to present information to the user. Sure, the team can accomplish this with concrete classes. Yet, interfaces provide a good and evident, well defined, language supported, barrier to stop the propagation of change. In particular if the team has good rules about responsibility (No, I do not mean code concerns, I mean, what developer is responsible of doing what).

回答2:

You should always use an abstraction of the layer to have the ability

to mock the interfaces in unit tests
to use fake implementations for faster development
to easily develop alternative implementations
to switch between different implementations
...

来源：https://stackoverflow.com/questions/44154495/why-do-we-require-interfaces-between-ui-business-and-data-access-in-c-sharp

标签

n-tier-architecture

3-tier