ASP.NET MVC DDD: why repeat the same code 3 times?

Question

ASP.NET

Good day!
I'm learning ASP.NET MVC and plan to write a fairly complex project soon.
Recently, I was thinking about how my application should be arranged, and began to look for different design approaches. During the search, I came across the following tutorial (
source code from the tutorial ).
Having studied the sources, I noticed that it contains exactly the same interfaces (IRepositoryBase, IServiceBase, IAppServiceBase), and the classes that implement these interfaces work as follows: for example, the Add (entity) method of the class that implements IAppServiceBase is called. This class calls the same method on the class that implements IServiceBase, which calls the same method on the class that implements IRepositoryBase.
I don't understand why it's so complicated.
Actually questions: what for 3 times to repeat the code? is this approach correct? what approaches do you use (preferably with asp.net mvc examples) ?

Answer 1

In fact, there are many approaches, and there are even more possible implementations of these approaches. The approach may differ depending on the task. Therefore, it is necessary to proceed from the task.

Answer 2

Good afternoon!
The correct approach is one that solves the problem effectively, quickly and simply. My activity is connected with projects on automation of business processes of customers. In such projects, it is better to divide all logic into several layers: a presentation layer (in particular, an application on ASP.NET MVC, WPF, WinForms), a business logic layer (a separate library, class library), a data access layer (also a separate library) .
I will describe an example.
In one of his personal projects on ASP.NET, just the division of logic into layers is used. There are several projects: MyApp.MVC, MyApp.DAL, MyApp.BL. Accordingly, the general scheme of work is as follows: in the controllers of the MyApp.MVC layer, methods from the MyApp.BL layer (business logic layer) are called. If a method from the MyApp.BL layer needs to work with database data, then it already calls the methods of the data layer (MyApp.DAL). The MyApp.DAL layer is already pulling/adding/modifying/deleting data directly. At the same time, the layers do not know about the specific implementations of the methods, since everything is based on interfaces and dependency inversion (DI and IoC container, in particular - Ninject). As a result, we get:
1. Separation of responsibility (everyone does only what he needs, that is, everyone performs his task).
2. Ease of maintenance (you need to change the data sampling logic - for example, change the SQL query. All changes will affect only the MyApp.DAL layer, in this case you don’t need to change other layers and they will be “on the drum”, which happens inside the MyApp.DAL layer ).
3. Component extensibility (by this I mean that you can take the MyApp.DAL layer and include it in another application).
4. Visibility (the code is cleaner and more consistent).
I'm sure it's not a "panacea", and in other types of projects (like games? complex math models?) this architecture can do more harm than good (like "thrashing" through interfaces, for example).