Gain insights into creating dynamic web apps with ASP.NET Core MVC. Explore Razor, localization, advanced features, and best practices for building public and business applications.

ASP.NET Core MVC (Intermediate)_468 x 60 copy.png

asp.tar.gz

ASP.NET

ASP.NET-multi

ASP.NET-Secure

ASP.NET-copy

In this course, you will learn how to create a modular, dynamic web application with ASP.NET Core MVC, Razor, and Razor tag-helpers. Furthermore, you will also learn how to localize that application in several languages, and finally how to publish it.

You will cover many different aspects of ASP.NET development including: how to optimize user interfaces, validate user input, how to write clean and maintainable code with dependency injection and configuration data, and a whole lot more.

By the end of this course, you will be able to build both a public website and a business application based on ASP.NET Core MVC, with advanced features such as caching, authentication, and authorizations, and while conforming to Microsoft best-practices.

ASP.NET Core MVC

# Classes mutual dependencies ##

In all object languages, objects need to call methods of other objects to do their job. This is called **object cooperation**.

Object cooperation must be carefully designed since complex patterns of object cooperation can undermine the whole application's modularity. In fact, a class that cooperates with too many other classes is likely to be changed each time one of the classes it "knows of" changes. 

The problematic acquaintances are not hardwired classes like the fundamental types (string, decimals, etc.) and classes that are part of the programming framework. This is because they are very unlikely to change, but all other application classes are likely to change as the application evolves and is maintained.

# Mitigating mutual dependencies with interfaces ##

A way to mitigate dependency on other classes is to hide acquaintances behind interfaces. One might object that this way, we move from the problem of dependency on other classes to an equivalent problem of dependency on other interfaces. However, this is not the case.

In fact, well-designed interfaces are specific to a single purpose, while classes are specific to roles and responsibilities that are evolving concepts with a wider scope. Roles, and the way they are implemented, changes with the application evolution since they are tied to the application needs. The methods and properties, on the other hand, are needed by the specific operation encoded into an interface are very unlikely to change as they are tied to the logical definition of the operation itself, and not to the application needs.

If interfaces are designed according to the **interface segregation principle**, then each interface is responsible for a single pattern of interaction. This means classes will evolve by changing the way they implement their methods, and by implementing several more interfaces, but the interfaces should not change.

We may conclude that each class should not depend on other classes but just on other interfaces. This means that each class should use just the framework/fundamental types and interface types. 

This would be an exaggeration since we previously discussed data-communication objects designed specifically to convey the data that must be processed to a module.

Let's reformulate: classes may contain references just to framework/fundamental types, interfaces, and pure data communication objects. 

# Getting the needed dependencies ##

Communication objects move according to the well-defined pattern of data communication among layers, so tracking their changes is not difficult during application maintenance. Their data content is defined by the needs of the target layer, and the way they are filled is confined next to the boundary between the two communicating layers.

What about interfaces? How can each object get all the interfaces it needs to work properly? It cannot create them since they are just interfaces, not classes. Therefore, these interfaces must be placed inside the object by other classes. But how can other classes inject interfaces into an object without knowing its type, and without depending on the object they must fill?

What we threw out of the main door is coming back from the backdoor! Filling objects with interfaces when they are created is a very dangerous task because it may create a complex network of mutual dependencies. That is worse than the original one we were trying to avoid!

The only solution is to create another type of entity that takes care of doing this job, in a way that doesn't depend on the application logic and on the way all classes will evolve. 

This is the injector. So we just discovered dependency injection.

# How dependency injection works ##

According to the dependency injection pattern, each class specifies all interfaces/types it needs in its constructor and/or in properties tagged for injection. Since objects are created by classes that manipulate more than just interfaces, they must be created by the dependency injection engine itself. This engine can take care of injecting all types they need in their constructors and in their tagged properties.

Where do the injected objects come from? Obviously, it is a developer's responsibility to define how to create all types to be injected.

For this purpose, we fill a kind of dictionary called dependency injection container with key-value pairs. The key is the type/interfaces that might be injected in a class, while the value is the concrete type that implements or is a subtype of that key.

Thus, for instance, an `ILogger` interface might be the key, and a concrete class that is able to log data is the value. A class just specifies the `ILogger` type in its constructor, then the dependency injection chooses the actual implementation.

Below is the definition of a class that needs a logging service:

In this lesson, we will learn a fundamental pattern for the cooperation between objects called dependency injection.

Razor Template Language

Razor Language Assessment

Tag Helpers

Tag Helpers Assessment

Controllers and ViewModels

Controllers Assessment

Validation and Metadata

Validation Assessment

Dependency Injection

Configuration and Options Framework

Localization and Globalization

Factoring out UI Logic

Authentication and Authorization

Advanced Topics Assessment

Publishing Your Web Application

Conclusion

Appendix

What is Dependency Injection?

Classes mutual dependencies

Mitigating mutual dependencies with interfaces