What is the easiest way to master dependency injection, code-first, TDD and patterns?

Question

ASP.NET

Good afternoon, dear colleagues!
I've been playing C# for two years, it all started with Web Forms, after some time I realized that I needed MVC. I immediately realized that I need to study patterns, dependency injection, code-first, test-driven development, etc. fashionable things (as far as I understood from the texts of vacancies fashionable).
I am currently reading a book by Adam Freeman, doing SportsStore. Here in his book everything is smooth there: this means a model, here is an interface, but here there is no need for an interface, here we introduce a dependency, but here we don’t. Somehow everything goes by itself, and why he decided to do it one way or another does not write.
Let's say an ideal situation - I decided to make a website, how can I understand what logic to put in the controller, which in the model, what methods - where to stick it, why exactly and not otherwise? I understand that patterns are needed here? That is, is there any information on how best to do this or that thing and why?
In general, all this is somehow difficult for me, apparently because there is no understanding, if you read a specific code, everything seems to be clear, but if you look at it as a whole, I don’t understand why this is done.
How would I solve this problem, please advise what to read and see?

Answer 1

Good evening! Thanks for the invitation.
In my opinion, you should adhere to the following study priorities:
Now for MVC.
1. Model - here, in principle, everything is simple: a data model. It can be argued here what is meant by Model: a model of the data itself or a presentation model . Personally, after working with the MVVM pattern in WPF, I understand the data model in terms of ASP.NET MVC as the view model , and the term "data model" means the domain model itself (EF code-first, for example). Some might say that it's "extra work" to pack the data model from EF objects into view model objects. Yes, I partially agree. But on the other hand, this gives a certain security guarantee that the user will not accidentally change an important part of the data model (for example, ID).
2. Controller. The main task of the controller is to generate data for display and pass this data to the view. Those. you should strive to ensure that the code of the action method in the controller contains a minimum of code. Ideally, calling a method from the business logic layer and passing the resulting data to the view. If you see that the action method in the controller contains some business logic, then this is a signal for refactoring: Your action method knows too much. From experience, I can add that, on average, the code of an action method contains from 2 to 20-30 lines of code (taking into account the fact that the { and } brackets are on separate lines).
3. Submission. Here, too, everything is simple: display data (from the view model). In no case should you write logic for working with the data itself in the view, for example, you can’t do this:

<div id="account">
    @{
        using(var db = new MyEfDbContext()
        {
            var userAccount = db.Accounts.FirstOrDefault(e => e.Username == User.Identity.Username);
            if(userAccount != null)
            {
                @:Имя: @userAccount.Name
                @:Фамилия: @userAccount.LastName
            }
        }
    }
</div>

If you have a 3-level architecture, for example, there are layers:
1. MyApp.MVC - MVC-application
2. MyApp.BL - business logic
layer 3. MyApp.DAL - data manipulation layer,
then call directly in the View business logic services are also not allowed, especially if you use the DI principle (dependency injection) and the IoC container. Those. this example is invalid:

<div id="account">
    @{
        var accountService = new MyApp.BL.AccountService();
        var userAccount = accountService.GetUserAccountByUsername(User.Identity.Name);
        if(userAccount != null)
        {
            @:Имя: @userAccount.Name
            @:Фамилия: @userAccount.LastName
        }
    }
</div>

I will try to convey the idea of ​​the architect and developer Alexander Shevchuk (teacher from http://itvdn.com):"One of the main goals in development is to strive to simplify the system." Relaxation of dependencies allows us to simplify the system due to the fact that the change is carried out only at 1 some layer / level. If you take out the logic for working with data in the View, and even more so, as in the examples above, working with the EF context, then you will increase the dependence of one system component (MVC layer) on another (data working layer or business layer). logic). Strengthening dependencies leads to more changes, which in turn increases the cost of this system. Relaxation of dependencies leads to fewer changes (for example, when moving from EF to native SQL or NHibernate, only the data layer is affected, and the MVC layer and business logic do not change), which means an earlier release of the system or the next release, and as a result, the cost reduction (not only monetary, but also other resources) for development. TDD can also be attributed to practices that reduce the cost of resources for maintaining the system. But it was I who went into the global ...
The correct approach would be when you reduce the dependence of the system components on each other, in the case of an ASP.NET MVC application, in my opinion, this is when:
- View knows about the model (I will still mean the view model - ViewModel, which are declared either in the MVC layer or in the business logic layer);
- the controller knows about the business logic layer, calls it to perform operations and get the ViewModel, and then passes the received ViewModel (well, or JSON data) to the View;
- Model is formed according to the principle, roughly speaking, almost every View has its own model.
I justify the phrase "the approach will be correct" by the fact that such an approach has a lot of advantages(which are obvious to experienced developers, but may not be fully or misunderstood by less experienced colleagues, namely):
+ View does not know anything about the domain model (only about the ViewModel), so you can safely change your domain model without making changes in View (see above about weakening dependencies and reducing the number of links). You can also easily switch from EF to NHibernate or native SQL, or both - the View will never know about it;
+ The controller (and the entire MVC layer) only knows about the existence of the business logic layer, but knows nothing about the data layer.
+ if you make a separate ViewModel on the View, then this allows you to more fully control what needs to be shown to the user. Those. gives you more control over the displayed data, increases the security of your application (for example, the user will not be able to change the ID of the viewed record if this ID is not in the view model at all).
Well, in general, it all depends on the task / project: whether it is necessary to apply a breakdown into layers or use ViewModels instead of conventional domain models - you need to think about each situation separately.
PSIn my opinion, the literature was chosen correctly - I also started learning MVC from it. I liked the fact that first a general description and work with ASP.NET MVC is given using a cross-cutting example. And then there is a deeper dive into ASP.NET MVC. For development, I can advise Alexander Byndyu's blog: blog.byndyu.ru It seems to me that some points are chewed very well there, including SOLID, TDD, the Repository template, UnitOfWork, etc.