如何将 class 名称用作通用参数？

Question

I understand generics in C# and they are used to keep things strongly typed. I'm using Entity Framework and I'm seeing the < > syntax used, but it seems to be naming a parameter for a method as opposed to a type.
For example

services.AddDbContext<MyDbContext>(options => options.UseSqlServer(...));

MyDbContext is not a type, it's a class needed to link the DB and Models together. But how is the syntax used here? Shouldn't it be....

 services.AddDbContext(MyDbContext);

Clearly I'm not understanding something about syntax here.

Answer 1

Broadly speaking, unless you've changed them, in recent VS properties would be colored white, types a sort of green and methods yellow.

If you take a look at the MyDbContext in the angle brackets of the first line of code, it will be a greenish kind of color:

services.AddDbContext<MyDbContext>(...)
                      ^^^^^^^^^^^
                   green means type

And in the second it would be white meaning a property representing some instance of a context somewhere (property because it's PascalCase not camelCase):

services.AddDbContext(MyDbContext)
                      ^^^^^^^^^^^
                   white means property

AddDbContext doesn't need an instance; it doesn't want an instance. An important part of what it does is set up dependency injection so that the injector provides instances of a db context: it just wants a type parameter so it knows what type of instances to provide (and how they're configured, options wise etc, what kind of database connection to use etc). Once it knows this it can eg create an instance of MyDbContext every time it sees a parameter of type MyDBContext being mentioned in a constructor

class WhateverController{
    WhateverController(MyDbContext x) <-- this constructor needs a MyDbContext; the injector will make one and supply it

}

As such, yes the type(or class; same thing) name you provide in the < > is a parameter, telling what type is being registered, but it actually being an instance of the type wouldn't be super helpful because the only thing the injector would reasonably do with it would be to inspect what type the instance is, remember the type and throw away the instance (because it wants to know the type, it doesn't want an instance - it's job is to create instances of the type for you)

---

When you write a generic method you're essentially giving the compiler a skeleton it can use to write methods for you. You specify the method as being generic by putting words in angle brackets and the compiler treats them as types that it can substitute for the types it sees you use when you use the method:

string GetDatedString<T>(T thing){
  return $"{DateTime.Now} {thing.ToString()}"( 
}

If you call this and provide an int the compiler can conceptually write an int flavored version, which means you don't have to write it.

string GetDatedString(int thing){
  return $"{DateTime.Now} {thing.ToString()}"( 
}

Writing one of those for every type in your program would be pretty horrific

---

There are times, and a good example is when you're setting up dependency injection, when you don't want to (or cannot create) an instance the type you want the injector to provide when it sees you using it. Suppose you have some type MyDbContext that implements interface IMyDbContext and you want the DI to inject an instance of MyDbContext every time it sees you using the interface IMyDbContext in a constructor. If your aim is to communicate the type-you-see and the type-you-shall-create to the injector via some method that took an instance, you'd end up having to cast your type:

services.AddDbContext((IMyDbContext)new MyDbContext());

Here we could do some trickery to stash the static (compile time) type IMyDbContext as well as the runtime type MyDbContext and then know "whenever i see IMyDbContext provide an instance of MyDbContext" but it's not so pretty and essentially still requires us to provide a useless instance when all the injector wants to know are types.. Being able to pass types as arguments without needing to pass instances is nice and clean and helps out with compile time type related goodness. Look at the ugly we had to do to parse an enum before generics:

Status myStatus = (Status)Enum.Parse(typeof(Status), "Active");

Compared to being able to specify a type argument:

Status myStatus = Enum.Parse<Status>("Active");

---

So all in, with that thing you asked about originally:

services.AddDbContext<MyDbContext>(...)

And another overload:

services.AddDbContext<IMyDbContext, MyDbContext>(...)

that are calls that take arguments that are types because we want it to be - the first is saying "when you come across a class calling for a MyDbContext, give it an instance of one, and the second overload of "when you come across a class calling for a IMyDbContext, give it a MyDbContext" - this letter form being very useful if you want to eg swap your real MyDbContext out for a FakeMyDbContext that also implements IMyDbContext; it looks like a real one for testing purposes but just generates fake data etc so tests run; you don't have to change any of your classes that call for an IMyDbContext, they just call the methods they see in the interface and testing or running your app for real is switched simply by telling the injector "when you see X provide Z instead of Y"