Episode 005 - Dependency Injection - ASP.NET Core: From 0 to overkill

In this post/video we continue our look into base concepts of ASP.NET Core, in preparation to what’s in our way for building the application. This time, dependency injection, which was built right into the core of ASP.NET Core (see what I did there? 😆).

In this post/video we continue our look into base concepts of ASP.NET Core, in preparation to what’s in our way for building the application. This time, dependency injection, which was built right into the core of ASP.NET Core (see what I did there? 😆).

For the walk-through you can check the next video, but if you prefer a quick read, skip to the written synthesis.

The playlist for the whole series is here.

Intro

In the last episode, we started looking into some important core concepts when developing ASP.NET Core applications, namely the Program and Startup classes, taking also a quick look into dependency injection and middlewares. In this episode, we go a little further with dependency injection.

Extracting logic from the controller

Why

Normally we don’t want our controllers to have too much logic, particularly business logic. Ideally the controllers focus on MVC/HTTP specific logic - receiving client inputs, pass them along to something responsible for the business logic, return the results back (feeding views or in other forms, such as a JSON payload), maybe including different HTTP status codes depending on the output of the business logic.

This, of course, isn’t mandatory, and I’ve seen articles and talks arguing that for instance, if we’re developing really small microservices, we might as well bypass splitting the code this way, as if adjustments are needed we could just rewrite the service. Anyway, I’ll go with the more classic approach of splitting things, just wanted to make the note that this isn’t set in stone (as nothing is really, there are always multiple ways of doing things).

Some benefits of having the business logic separated from the web framework are the ability to test it without the complexity added by the web framework specificities, as well as allowing the use of the same logic components with different “gateways” (an alternative web framework, a desktop application, etc).

New class libraries

To extract the business logic from the controller, we’ll go along with the old school 3-tier architecture, where our MVC application will be the presentation layer and the extracted logic will make up the business layer. No data layer yet, we’ll get to it in the future.

N-tier architectures may not be what’s hot right now, but for what we’re doing right now, it fits our needs and is simple enough.

Starting with the creation of couple of class libraries CodingMilitia.PlayBall.GroupManagement.Business and CodingMilitia.PlayBall.GroupManagement.Business.Impl. The first library will contain the contracts/API that the clients of the business logic need to know, while the latter will contain the implementation of said logic.

In the contracts library, we need the models (Group class only in this case) and the IGroupService interface.

public class Group
{
    public long Id { get; set; }
    public string Name { get; set; }
}
public interface IGroupsService
{
    IReadOnlyCollection<Group> GetAll();
Group GetById(long id);

Group Update(Group group);

Group Add(Group group);

}

Going to the service implementation library, we create a InMemoryGroupsService class that implements the IGroupsService interface - there isn’t much business logic right now, it’s mostly CRUD, but let’s pretend there is 😛

public class InMemoryGroupsService : IGroupsService
{
private readonly List<Group> _groups = new List<Group>();
private long _currentId = 0;

public IReadOnlyCollection&lt;Group&gt; GetAll()
{
    return _groups.AsReadOnly();
}

public Group GetById(long id)
{
    return _groups.SingleOrDefault(g =&gt; g.Id == id);
}

public Group Update(Group group)
{
    var toUpdate = _groups.SingleOrDefault(g =&gt; g.Id == group.Id);

    if (toUpdate == null)
    {
        return null;
    }

    toUpdate.Name = group.Name;
    return toUpdate;
}

public Group Add(Group group)
{
    group.Id = ++_currentId;
    _groups.Add(group);
    return group;
}

}

As the name implies, the data is stored in memory (it’s not even thread safe) so to say it’s far from production ready is an understatement. It’s exactly the same logic we had in the controller, just pulled into a class of its own.

Heading back to the web application project, we add the references to the newly created libraries and rework the GroupsController to use the IGroupsService instead of having the logic implemented in it.

[Route("groups")]
public class GroupsController : Controller
{
private readonly IGroupsService _groupsService;

public GroupsController(IGroupsService groupsService)
{
    _groupsService = groupsService;
}

[HttpGet]
[Route("")]
public IActionResult Index()
{
    return View(_groupsService.GetAll().ToViewModel());
}

[HttpGet]
[Route("{id}")]
public IActionResult Details(long id)
{
    var group = _groupsService.GetById(id);

    if (group == null)
    {
        return NotFound();
    }

    return View(group.ToViewModel());
}

[HttpPost]
[Route("{id}")]
[ValidateAntiForgeryToken]
public IActionResult Edit(long id, GroupViewModel model)
{
    var group = _groupsService.Update(model.ToServiceModel());

    if (group == null)
    {
        return NotFound();
    }

    return RedirectToAction("Index");
}

[HttpGet]
[Route("create")]
public IActionResult Create()
{
    return View();
}

[HttpPost]
[Route("")]
[ValidateAntiForgeryToken]
public IActionResult CreateReally(GroupViewModel model)
{
    _groupsService.Add(model.ToServiceModel());

    return RedirectToAction("Index");
}

}

A couple of things to notice:

  • We’re now receiving the IGroupsService in the constructor, so we can use it in the actions
  • ToViewModel and ToServiceModel extension methods - as the presentation layer and the business layer use a different set of models, we need to convert them when passing them along
public static class GroupMappings
{
public static GroupViewModel ToViewModel(this Group model)
{
return model != null ? new GroupViewModel { Id = model.Id, Name = model.Name } : null;
}

public static Group ToServiceModel(this GroupViewModel model)
{
    return model != null ? new Group { Id = model.Id, Name = model.Name } : null;
}

public static IReadOnlyCollection&lt;GroupViewModel&gt; ToViewModel(this IReadOnlyCollection&lt;Group&gt; models)
{
    if (models.Count == 0)
    {
        return Array.Empty&lt;GroupViewModel&gt;();
    }

    var groups = new GroupViewModel[models.Count];
    var i = 0;
    foreach (var model in models)
    {
        groups[i] = model.ToViewModel();
        ++i;
    }

    return new ReadOnlyCollection&lt;GroupViewModel&gt;(groups);
}

}

We could do this mapping directly in the controller, but it would end up being polluted by this boilerplate code. We could also use AutoMapper to do this auto-magically for us, but it can sometimes hide problems in our code (for instance, we can’t be sure of the existence of references to properties when using it). All in all, I like this extension method idea by a colleague of mine, as it provides nice readability in the controller, so I’ll go with it.

If we try to run this now we’ll get an error, because we’re now expecting to get an IGroupsService in the controller, but we haven’t told the framework how to get it. To do this we need to register the service implementation in the dependency injection container.

Using the builtin container

Registering the service

In the previous episode we saw how to register services in the builtin dependency injection container, and this will be no different. We want to register the InMemoryGroupsService and like we also saw previously, we want it to have lifestyle of type singleton, so the data it keeps in memory sticks around for the lifetime of the application.

To do this, we need a single new line added to the Startup class: services.AddSingleton<IGroupsService, InMemoryGroupsService>();.

Now we can run the application and it behaves has before, just with a different internal organization.

Improve organization

For now, we don’t have too much to worry, as we only have a couple of lines in the ConfigureServices method of the Startup class, but what about when we add more and more?

One good way of keeping the ConfigureServices tidy is to create extension methods on IServiceCollection to register groups of services that go along together. With this in mind, in a newly created IoC folder, we add a new class ServiceCollectionExtensions.

namespace Microsoft.Extensions.DependencyInjection
{
public static class ServiceCollectionExtensions
{
public static IServiceCollection AddBusiness(this IServiceCollection services)
{
services.AddSingleton<IGroupsService, InMemoryGroupsService>();

        //more business services...

        return services;
    }
}

}

Notice the namespace “trick” in there, using the same namespace as IServiceCollection. This is something usually done to ease discoverability of extension methods, as it allows for us to go to the ConfigureServicesmethod, type services. and get immediately the methods in intellisense without the need to add another using.

Now in the ConfigureServices we can replace the line we added previously with services.AddBusiness();.

Using third party containers

It’s good that ASP.NET Core comes with dependency injection built right into it, but we need to keep in mind that the out of the box container was built to answer ASP.NET Core internal needs, not every need of the applications built on top of it.

For more advanced scenarios we might have, we can use third party DI containers that can provide those features.

Just to check out this possibility, we’ll add Autofac to the project and play a little with it. The objective is not to go into much detail on Autofac itself, but see how to use it with ASP.NET Core and an example of extra features it adds.

Replacing the container

First thing is to add a couple of NuGet packages - Autofac and Autofac.Extensions.DependencyInjection.

To register dependencies with Autofac, we create a new class AutofacModule(in the IoC folder) that inherits from Module and we override the Loadmethod.

public class AutofacModule : Module
{
protected override void Load(ContainerBuilder builder)
{
builder
.RegisterType<InMemoryGroupsService>()
.As<IGroupsService>()
.SingleInstance();
}
}

The code seen above is the equivalent of what we had in AddBusiness, but adapted to Autofac’s API. Now we need to configure Autofac as the container.

//...
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();

//if using default DI container, uncomment
//services.AddBusiness();

// Add Autofac
var containerBuilder = new ContainerBuilder();
containerBuilder.RegisterModule&lt;AutofacModule&gt;();
containerBuilder.Populate(services);
var container = containerBuilder.Build();
return new AutofacServiceProvider(container);

}
//...

The first change to notice is the ConfigureServices method is no longer void, it now returns an IServiceProvider. This is needed so ASP.NET Core uses the returned service provider instead of building its own out of the IServiceCollection that’s received as an argument.

The Autofac configuration code by the end of the method is a plain copy paste from Microsoft’s dependency injection docs 😇

Basically, what we’re doing here is:

  • Creating an Autofac container builder
  • Registering the module we created with our dependency configurations
  • Populating Autofac’s container with the registrations present in the IServiceCollection, put there by ASP.NET Core’s components
  • Building the container
  • Return a new service provider, implemented using the Autofac container

Again, rerunning the application, we maintain the same functionality.

Using other container features

So far we haven’t used any specific feature of Autofac that justifies the change, unless it was a matter of performance (which wouldn’t be the case, at least at the time of writing, the builtin container seems faster, see here).

Just for arguments sake, let’s use an extra feature Autofac provides: decorators.

public class AutofacModule : Module
{
protected override void Load(ContainerBuilder builder)
{
builder
.RegisterType<InMemoryGroupsService>()
.Named<IGroupsService>("groupsService")
.SingleInstance();
builder
.RegisterDecorator<IGroupsService>(
(context, service) => new GroupsServiceDecorator(service),
"groupsService");
}

private class GroupsServiceDecorator : IGroupsService
{
    private readonly IGroupsService _inner;

    public GroupsServiceDecorator(IGroupsService inner)
    {
        _inner = inner;
    }

    public IReadOnlyCollection&lt;Group&gt; GetAll()
    {
        Console.WriteLine($"######### Helloooooo from {nameof(GetAll)} #########");
        return _inner.GetAll();
    }

    public Group GetById(long id)
    {
        Console.WriteLine($"######### Helloooooo from {nameof(GetById)} #########");
        return _inner.GetById(id);
    }

    public Group Update(Group group)
    {
        Console.WriteLine($"######### Helloooooo from {nameof(Update)} #########");
        return _inner.Update(group);
    }

    public Group Add(Group group)
    {
        Console.WriteLine($"######### Helloooooo from {nameof(Add)} #########");
        return _inner.Add(group);
    }
}

}

The decorator implements the IGroupsService interface, writing to the console on every method call, then delegating the real work to another IGroupsService implementation it gets in the constructor.

To register the decorator, we changed the InMemoryGroupsServiceregistration to a named one, and then call RegisterDecorator with a lambda to build the decorator and the name we added to the real implementation’s registration. Can’t say I’m the biggest fan of this API, but that’s what we have right now.

Now if we rerun the application, we keep the same functionality as before, but additionally if we look at the console, intermixed with the logs we see the decorators messages.

Outro

This is it for a quick look at dependency injection in ASP.NET Core. Even though not going very deep it’s good enough to prepare for what’s coming, and we’ll introduce more related concepts as needed along the way.

Using Autofac was good for an introduction on replacing the builtin container, but I’m not entirely sold on its API, I’ll probably replace it in the future.

The source code for this post is here.

Please send any feedback you have, so the next posts/videos can be better and even adjusted to more interesting topics.


By : JoĂŁo Antunes


Introduction to ASP.NET Core Tutorials | ASP.NET Training | Simpliv

Introduction to ASP.NET Core Tutorials | ASP.NET Training | Simpliv

This course is designed you give you a deep understanding of modern .NET concepts without confusing you or making you lost in the sea of .net technologies that keep springing up now and then. Get behind the modern .NET directions and grasp all that is going on nowadays in the world of .NET.

Description
Last years a great number of technologies came up to the world of .NET platform: nowadays we have the full (classic) .NET framework with CLR as a runtime, Mono with its own runtime, .NET Core with Core CLR, WinRT, UWP and Xamarin, a new JIT compiler RyuJit, .NET Standard, PCL, .Net Native, new Roslyncompiler with open API, NuGet based project management. God’s sake! It’s so simple to get lost in that ocean of technologies. You need to understand the overall picture to feel comfortable today. Didn’t you feel like a small fish in the ocean last time? Well, I did. I questioned myself, "what the hell is going on around me?" I didn’t quite understand the directions in which technologies develop. I didn’t know what to expect, what to learn next. In such situation, you feel helpless. And what we are going to do in the course is that we’re going to eliminate this nasty feeling of being helpless by learning all the most important notions in the modern .NET platform.

Teaching Approach

No fluff, no ranting, no beating the air. I esteem your time. The course material is succinct, yet comprehensive. All important concepts are covered. For absolute beginners, I offer my help on Skype absolutely free if requested. Don't forget that this course has English subtitles, so if you don't understand my accent, feel free to turn them on.

Take this course and you will be satisfied.

Build a deep understanding of modern .NET concepts

If you go behind the modern .NET directions, then this course is for you. This course will bring a whole picture of what's going on nowadays in the world of .NET, so you'll understand what you can and what you can't achieve using specific technologies. This course is like a navigation map.

Content and Overview

The goal of this course is to reveal the whole picture of the .NET world. One of the most profound technologies is the new .NET Core platform, so learning it, is a second primary goal of this course.

Of course, all the way along we will discuss all the other technologies I mentioned above.

This course is built for all kind of C# developers who are interested in learning the .NET platform. This course is beneficial for juniors as well as for seniors who want to stay well-informed about modern .NET platform. I’m sure any student will find something interesting and useful in this course.

The main prerequisite is to be familiar with development on the .NET platform in C#. That’s all you need.

In short, the course covers the following topics:

Classic .net platform, it’s building blocks, the history of this platform
Mono platform, it’s building blocks. You’ll figure out if classic .NET and Mono are compatible. We will compare classic .NET framework and Mono platform
.NET Core is the new cross-platform .NET platform. We will understand what’s different here comparing to other .NET platform and this platform means for the future of the .NET world platform
.NET Native is an interesting ahead-of-time compilation technology. You’ll know that a form of .NET Native comes to .NET Core as well.
Do you really understand what is UWP? How it is related to WinRT and what WinRT actually is?
Roslyn as a compiler platform
NuGet as a system of dependencies management
Installation of .NET Core
Command-Line Interface (CLI) of .NET Core
Deployment in .NET Core: SCD and FDD
The problem of cross-compiling
Portable Class Library (PCL)
.NET Standard
.NET Portability Analyzer
Unit-Testing in .NET Core
Upcoming Changes quick overview
How long is this course: The course is around 2 hours. All are video lectures. You will be able to download all the slides and code samples used in the course.

Keywords related to the course:

.NET Core
C#.NET Core
.NET Standard
NuGet
Core CLR
.NET Ecosystem
Who is the target audience?

Anyone from beginner to senior
Basic knowledge
Need to be familiar with development on the .NET platform in C#
What will you learn
Create, deploy and manage .NET Core applications
Disctinct different technologies: platforms, runtimes, compilers and so on
Create and use .NET Standard Libraries
Understand all the modern .NET concepts
Write unit-tests in .NET Core
To continue:

PHP Vs ASP.NET: How to Choose the Right One?

PHP Vs ASP.NET: How to Choose the Right One?

Are you a business owner looking for PHP web development services or ASP.Net development services, but unable to decide the right technology for your project? Are you looking for the pros and cons of ASP.Net and PHP to take an effective...

Are you a business owner looking for PHP web development services or ASP .Net development services, but unable to decide the right technology for your project? Are you looking for the pros and cons of ASP .Net and PHP to take an effective decision?

We have no doubt about the fact that both of these technologies have become successful ventures, and have developed great websites.

But, the question still remains fresh for all of us, especially those from a non-technical background and the question is: Which platform should we choose at the time of starting with web-apps exercise?

On one side, PHP is a free and open-source platform while ASP .Net is a paid Microsoft platform. PHP is a mix between a programming language and a web framework whereas .NET is a straight application framework.

Now, Let’s have a neat and clean comparison on PHP & DotNet on different parameters.

In the below blog, I have covered the differences between the two and tried to decipher which is the better one.

Read the full blog here: PHP Vs ASP.NET: How to Choose the Right One?

Create Login and Registration in Your ASP.NET Core MVC App

Create Login and Registration in Your ASP.NET Core MVC App

This tutorial walks you through setting up login and registration with ASP.NET Core MVC. In this tutorial, you learned how to add authentication to your ASP.NET Core MVC app and allow users to register for a new account.

This tutorial walks you through setting up login and registration with ASP.NET Core MVC. In this tutorial, you learned how to add authentication to your ASP.NET Core MVC app and allow users to register for a new account.

User authentication and authorization are common features in web applications, but building these mechanics has the potential to take a lot of time. Doing so requires setting up persistent storage for user information (in some type of database) and paying keen attention to potential security issues around sensitive operations like hashing passwords, password reset workflows, etc. - weeks of development time begin to add up before we ever get to the functionality that delivers value to your users.

In this post, we’ll walk through how Okta simplifies this process for us and set up a simple integration for an ASP.NET Core MVC app using the Okta NuGet package. We’ll build functionality for users to register for new accounts and login with their Okta credentials.

Scaffold Your ASP.NET Project

To follow along with this tutorial start by creating a new app in the console:

mkdir MyOktaProject
cd MyOktaProject
dotnet new mvc


Configure User Registration

If you don’t already have one, you’ll need to create an Okta developer account. Doing so will give you a URL for your organization called an “Okta domain”. It will also allow you to create your login credentials for accessing the Okta dashboard.

Upon submission of this form, you will receive an email Okta with instructions to obtain your credentials and complete your registration.

Execute the following steps to configure Okta so that users can register themselves for an account.

  1. From the Administrative Dashboard, hover over Users and click Registration
  2. Click Enable Registration
  3. Save the changes

Configure Basic User Authentication

Once you have access to your account you can proceed to the Dashboard using a link like the one below:

<span

class="okta-preview-domain">https://{yourOktaDomain}/admin/dashboard

On the Dashboard, click Applications in the main menu and on the Application screen, click Add Application.

Select Web then click Next.

On the Create New Application screen, set the following values:

Click Done, then click Edit next to General Settings on your newly created Okta app. Edit the following values:

Logout redirect URIs: https://localhost:5001/signout-callback-oidc

Initiate login URI: https://localhost:5001/authorization-code/callback

Add .NET Authentication Dependencies

Once your account is set up you need to add the Okta.Sdk library to your project. This post will take the approach of using the NuGet package, but the Github repository for Okta.AspNetCore can be found here.

To proceed simply search for the latest version of the Okta.Sdk NuGet package in your IDE of choice (version 1.2.0 at the time of this publication) and install it. If you’re using Visual Studio you can do this by right-clicking on the project in the solution explorer and selecting Manage NuGet Packages. For those of you not using Visual Studio, add the package via console window using the following command:

dotnet add package Okta.Sdk --version 1.2.0


Configure Your ASP.NET App for Login

Authentication works by redirecting users to the Okta website, where they will log in with their credentials, and then be returned to your site via the URL you configured above.

Add the following code to your appsettings.json file:

  "Okta": {
    "Issuer": "https://{yourOktaDomain}/oauth2/default",
    "ClientId": "{yourClientId}",
    "ClientSecret": "{yourClientSecret}"
  }


You can find each of the actual values needed to replace the settings in the config above in the following places:

ClientId refers to the client ID of the Okta application ClientSecret refers to the client secret of the Okta application Issuer will need the text {yourOktaDomain} replaced with your Okta domain, found at the top-right of the Dashboard page

Add some using statements to your Startup.cs file:

using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Authentication.OpenIdConnect;
using Microsoft.IdentityModel.Tokens;


Add the following code to the top of the ConfigureServices method in your Startup.cs file:

services.AddAuthentication(sharedOptions =>
{
    sharedOptions.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    sharedOptions.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    sharedOptions.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
    .AddCookie()
    .AddOpenIdConnect(options =>
    {
        options.ClientId = Configuration["okta:ClientId"];
        options.ClientSecret = Configuration["okta:ClientSecret"];
        options.Authority = Configuration["okta:Issuer"];
        options.CallbackPath = "/authorization-code/callback";
        options.ResponseType = "code";
        options.SaveTokens = true;
        options.UseTokenLifetime = false;
        options.GetClaimsFromUserInfoEndpoint = true;
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.TokenValidationParameters = new TokenValidationParameters
        {
            NameClaimType = "name"
        };
    });


In the Configure() method of your Startup.cs file add this line just before the app.UseMvc() method:

app.UseAuthentication();


Add the following MeViewModel to the Models directory:

using System.Collections.Generic;

namespace OktaAspNetCoreMvc.Models
{
    public class MeViewModel
    {
        public string Username { get; set; }

        public bool SdkAvailable { get; set; }

        public dynamic UserInfo { get; set; }

        public IEnumerable<string> Groups { get; set; }
    }
}


Add Login to Your ASP.NET App

Now that all the configuration and plumbing is done, you’re ready to add the code that will actually log users into your application.

Add the following AccountController to the Controller directory.

The controller exposes the Login() action. If the user has already been authenticated, the Login() action will redirect them to the home page. Otherwise, it will redirect them to the Okta login screen.

using Microsoft.AspNetCore.Authentication.OpenIdConnect;
using Microsoft.AspNetCore.Mvc;
using Okta.Sdk;

namespace OktaAspNetCoreMvc.Controllers
{
    public class AccountController : Controller
    {
        private readonly IOktaClient _oktaClient;

        public AccountController(IOktaClient oktaClient = null)
        {
            _oktaClient = oktaClient;
        }

        public IActionResult Login()
        {
            if (!HttpContext.User.Identity.IsAuthenticated)
            {
                return Challenge(OpenIdConnectDefaults.AuthenticationScheme);
            }

            return RedirectToAction("Index", "Home");
        }
    }
}


Add the following code to your _Layout.cshtml file, just below the main menu to add the login button, or a welcome message, based on the current user’s status.:

   @if (User.Identity.IsAuthenticated)
    {
        <ul class="nav navbar-nav navbar-right">
            <li><p class="navbar-text">Hello, @User.Identity.Name</p></li>
        </ul>
    }
    else
    {
        <ul class="nav navbar-nav navbar-right">
            <li><a asp-controller="Account" asp-action="Login">Log in</a></li>
        </ul>
    }


For information on user authorization using Okta groups check out Lee Brandt’s article on user authorization in ASP.NET Core with Okta.

Register Users

If you following the instructions above to enable self-service registration the “Don’t have an account? Sign Up” message will appear at the bottom of the login form. In the next step, you’ll run the application.

Log In Using ASP.NET

That’s it! To run your solution open up a terminal and enter the following command:

dotnet run


Then navigate to http://localhost:5001 in your browser and enjoy!

The source code for this tutorial is available on GitHub.

Now you have a website with a working login and user registration form. Your website also allows users to recover lost passwords. By repeating these steps you can create a network of tools that your users can access all with the same login.

Learn More

☞ The Complete ASP.NET MVC 5 Course

☞ Build a Real-world App with ASP.NET Core and Angular 2 (4+)

☞ ASP NET Core (ASP.NET 5),MVC 6,C#,Angular2 & EF Crash Course

☞ Rest Api’s in Asp.Net and C#

☞ Hands on ASP .Net Core 2