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

In this lesson, we will analyze the communication patterns between controllers and previous layers. However, we first need to list all the options we have for injecting service in controllers and views.

# Injecting services in controllers and views ##
Controllers and Views are added to the dependency injection container, so all parameters of their constructors are automatically filled by the dependency injection engine.

We already experimented with injecting services in controllers' constructors in the previous lesson. We just need to declare all services we need in the controller's constructor.We can store them in private/protected fields so they can be used in all controllers' methods.

However, services can also be injected directly into action methods. It is enough to declare them as action method parameters and precede them with the `[FromServices]` annotation. Thus, in the example of the previous lesson, we might have injected `ICostumerRepository` in each action method instead of injecting it in the constructor, as shown in the example below:













[HttpPost]
public IActionResult Edit(Customer model, [FromServices] ICostumerRepository repo)
{
    ...
        repo.Modify(model);
        return RedirectToAction(nameof(HomeController.Index));
    ...
}

Which of the two techniques we use is just a matter of modularity: if a service is used by just a single action method, inject it directly into that action method. If, the same service is used by several methods in the controller, it is best to inject it into the constructor.

For what concerns views, we don't define any constructor when we code them. Constructors are automatically created when views are compiled into classes. The example below defines the parameters that must be injected instances from the dependency injection container in a view:

@model ....
@using ...
...
@inject MyOptions o

Injectable parameters are declared with directives at the top of the view with the `@inject` keyword followed by the type to inject and the parameter where to inject it. Parameters defined in `@inject` directives can be used throughout the whole view.

It is important to understand what kind of services are better injected in views instead of controllers. The answer is in the separation of concerns between controllers and views. Business services, database services, and other services connected with the application logic must be injected into controllers.

We can just inject services that must be used for specific graphic tasks in the views. This includes services or translating text contents in various languages and application options that impact the graphics of the web page, such as the theme used, or the number of links to show in a pager. We will describe translation services in the chapter dedicated to globalization and localization.

# The repository pattern ## 

In the previous lesson, we defined a `CostumerRepository` service and its `ICostumerRepository` abstraction and called it a **repository**. Now, we will give a more formal definition of what a repository is.

According to the repository pattern, a repository is a unit of abstraction of the database layer. The whole database layer is abstracted as a set of repository interfaces whose methods are completely independent of the underlying storage engine. Dependency on the specific storage engine is encapsulated in the implementations of the repository interfaces. 

So, repository interfaces are just a way to abstract all database operations. What is the criteria for grouping several operations in the same repository interface? 

Roughly, there is a repository for each entity of the database conceptual model. However, not all entities have a dedicated repository, just the main entities that have a completely independent identity. 
For instance, the items of a purchase order, that can live only within that specific purchase order, have no repository associated with them but are handled by the repository associated with the purchase order. 

More pragmatically, purchase order items are not units of update. The user can't update a single item while simultaneously another user updates another item of the same order. When we update a single item of a purchase order the whole order must be locked, and not just that single item, otherwise, incongruencies may arise. 

## Aggregates ###

If a purchase order contains 3 pencils of type A and 2 pencils of type B, we might decide that we need one more pencil. We change the quantity of A pencils to 4. Now, suppose that simultaneously, another operator of the same company makes the same consideration, but increases the quantity of the B pencils. The result is that, we end up increasing the total quantity of pencils by 2.

Since, purchase orders are `update-units`, we can't update a single part of them without accounting for the remainder of the purchase order. The correct way to update a purchase order is to show the whole order to the user and let them modify it as a whole.

Summing up, entities must be grouped into **aggregates**. These must always be updated together, and for each aggregate, we define a corresponding repository abstraction.

In the example of the previous lesson, our aggregate contained just one entity, the customer. In general, aggregates may contain several entity types, and aggregates must be mapped one-to-one to repository abstractions. 

We can act on each aggregate with a different repository, so, if an operation involves several aggregates, one must use several repositories. However, what if all operations must be executed in a single transaction? That is, either all operations are successful, or if one fails all previous operations are undone.

# The Unit-of-Work pattern ##

According to the unit-of-work pattern, the whole transactional logic must be abstracted in an `IUnitOfWork` interface that has a `SaveChanges` or `SaveChangesAsync` method.

All repositories perform their operations, but all operations remain in a suspended state. They are actually applied when this `IUnitOfWork.SaveChanges` or `IUnitOfWork.SaveChangesAsync` is called. 

If we use an ORM to interact with the underlying storage, behind the curtain all repository operations affect just in-memory copies of entities. The underlying storage is updated only when `IUnitOfWork.SaveChanges` or `IUnitOfWork.SaveChangesAsync` is called.

If the flux of control also depends on current database values, repositories must interact with the actual database before calling `IUnitOfWork.SaveChanges` or `IUnitOfWork.SaveChangesAsync`. In this case, an actual database transaction must be started and either committed or aborted. That is why `IUnitOfWork` usually contains `StartAsync()`, `CommitAsync()`, and `RollbackAsync()` methods. The code below shows a typical definition of `IUnitOfWork`:

In this lesson, we will learn the various options for injecting services in controllers and views. We will also look at structured patterns of interaction between controllers and database or business layer that leverage the power of 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

Getting Services in Controllers and Views