>> Hey friends, we are continuing our ASP.NET Core one-to-one video series. In the last video, we made a very very
simple Web API that was really showing how
one could make a Web API, but I'm not feeling too proud of it. >> Yeah. It's not the most
ideal way to go about it. >> Yeah. It's not the most ideal way, but it's showed us a bit of plumbing, a bit of the internals of ASP.NET. We ended up doing it in basically
three lines in startup. Leslie is feeling gross about, I'm feeling gross about it. It's not bad, we're teasing
each other a little bit here. But the point is that's
if you do it manually, let's not do it that way, shall we? >> Yeah. >> All right. >> Why don't we separate all of this stuff out into
its own separate spot. >> Right. Because we've
been talking about the need for a single responsibility principle or what do they call that,
separation of concerns? >> Yeah. >> Then we did this horrible thing. >> Yeah. We've got to
practice what we preach. >> So I comment that out, I'm
going to say, "Control K", "Control C", look at that. >> Awesome. >> Comment that out, so we
no longer have a Web API. Earlier, you may made me
make a "Models" folder, and that's where we're
currently keeping things, and "Pages" are views. So we've got models and views. >> Yeah. So I guess all that's
missing is the controller. >> Right. >> For those of you
you're familiar with MVC, or model view controller. >> ASP.NET is a very
flexible web framework; you can make APIs, you can make Model-View-Controller
type things, you can make just pages
within page model, and you can mix and match them all. It's not really prescriptive, you can do what makes you happy. All right, let's do that. So I'll just make a folder, if that's okay. >> Yep. >> "Add" "New Folder", "Controllers", is it that cool? >> Then we can call the new
file ProductControllers. >> So I'm going to say, "Add". >> Or ProductsController. >> "Controller" products, plural. This is interesting. So when
I said "Add" "Controller", I could have said add class. >> Yeah. >> But I said add controller
and they're giving me a little bit more feedback. Here I could make an
empty API controller, I think that probably
worked for our needs. >> Yeah, that sounds about right
since we're enhancing our API. >> So we'll say "Add" and then we'll say
"ProductsController" plural. That's going to go
and scaffold that out and create them. Just take a moment. When we create this,
we're going to have the products model and
the products controller. >> So why even have then
MVC? What's the point? >> That is a good question, and the idea is that in
separation of concerns, you want to have the model that
knows how to talk to the database. You want to have the controller, that is your orchestrator, that has left hand in the
database and right hand in the views, and then your views. Views know nothing about anything. They only know about how to
display information, display data. >> Again, that's great
because it's like the whole ignorance
is bliss for code. If you want to reuse the
stuff or expand on it later, it's a lot easier to
do that if you don't have so many dependencies between. >> You said that before, that
idea if ignorance is bliss, and let's make sure that
that's a joke that people get because it really
makes sense though. If your object knows nothing about anything other
than it's one job, it's a much more useful object. >> Yeah, absolutely. >> If your object knows
all about the Internet, and then the Internet goes
away, who knows what happens? >> I don't know. But the problem
is if it knows everything, you end up with these
giant monolith classes that you've probably seen before, you've probably made one before if you're not new to programming itself, and then regret it
later when you try to find or do anything
else with that later. >> Exactly. So we just
created a ProductsController, and ProductsController
has this controller base that it derives from, it inherits behaviors
from ControllerBase. So it can do stuff that
ControllerBase can do. >> Again, that was
nice of Visual Studio. It did all this for us
so we didn't have to figure out what we
needed to be extending. >> When we made a new controller, we got this for free. >> Yeah. >> It is an APIController and
it meets a certain route, and we will figure out how
to plug these things in. Right now, it doesn't
really do anything. We could have made one that did
more stuff but that's fine. >> Yeah. So speaking
of making it do stuff, maybe we should add. >> Make it do some stuff. >> Yeah. >> Now in this case here, they've got us putting
it at API/Controller. This is products, I wanted
to just state products. So if it's called a view, I will delete that because it
could be full/power/products. >> Yeah. You can include
whatever crazy route you want. >> I want our route to be
super basic, if that okay. Then we're going to make a constructor because it needs
to construct things, right? >> Yes. >> So what do we call
here ProductsController, and I'll just make a
regular default one. >> You know that service that we
made a while ago, was JSON file? >> Yeah. JSON File. JSON
File product service, that's where our products come from. We're going to
need one of those. >> Yeah. Maybe you should
the take advantage of that. >> So we could new one, we can make one in the old
days but now we're using the services technique that is
available to us in ASP.NET. So we don't actually knew them, we don't go var j equals new. Instead, we just ask
for them and we ask for them by adding them
to our constructor. We can ask at, remember the login? >> Yes. >> We can add login. If
you take a look one of our previous videos we had login, this controller could
have that as well. >> It's great. >> That's cool. Then we
need to hold it somewhere, have it lying around
somewhere so we'll go and say, "JsonFileProductService". Then we need to be able
to get that, whenever. >> Yeah. We don't need to
modify right now either. >> Then we'll say
this product service equals that product service. So when who makes controllers right? I mean, we don't.
ASP.NET just makes them. >> Yeah. >> There's a controller
factory in fact. Yeah. Every time you make a call, the controller factory
says, "Product controllers? What does a product controller need? It needs these services.
It needs login. It needs JSON File product service." Wires it all up and says,
"Here, I made it for you." >> Going back to
design patterns days. >> It is. Yeah, it is
exactly what it is, it is a nice design pattern. That is our basic thing here. Before when we did a page, you're never doing razor pages, in the code behind, we said, "On get." There's a similar model, if you're going to do things
with controllers, isn't there? >> Yeah. I believe it
has to do with HTTP. So you'd have HTTP POST or GET. Let's use GET in this case. >> Yeah. Exactly right. So we're going to make a
method that returns product. Again, I'm going to hit control dot. The control dot pops up that menu. We're going to do
Get into your point, it will be in HTTP. Look at that. >> Awesome. So many options >> There's a list of all the verbs. >> So I can pick some of
the more obscure verbs, we'll use some of the more
obscure ones a little bit later. When people Get stuff,
call Get, cool. Notice how it's
threatening me right now, hey and not all paths return a value. >> Not returning anything. >> In fact, nothing is happening. Well, where do products live
in the service? Return. >> ProductsService. >>.GetProducts. Cool. Let's
compare these for a second. So this is a nice clean Controller
with a lot of flexibility. You can change the route. It doesn't really know anything about anything. It just does one job, it is a broker. >> That's pretty great. >> Look at this, compare
that to what we did before. >> So much nicer, notice all those [inaudible] function calls happening in just that first line alone. It's really messy and not. >> There's a lot going on here. We're digging around. We went digging for our service, and we went manually serializing. This is a great point here, this line here what we call
the JSON serializer ourselves. We didn't mentioned JSON. >> Yeah, because we already put
it in that product service. >> Let's see if it
works though. Here we are complementing each other. But we don't know, what
if it doesn't work? Somehow, that would
be bad. Let's give it a try. So we'll run it again. >> Our whole talk. >> Yeah, we are all talk, who knows. Products. Well, I have a thought, I bet you it's capital P. >> No. >> No interesting. Let's go find out what's going on. Did we tell ASP.NET that
controllers are a thing even? >> I don't think we did, maybe we shouldn't neglect
that startup file after all. >> That's what you get. >> Yep. >> We're talking smack trying
to compliment each other. >> Talking a good game. Well, we mentioned before that our application uses
routing and uses endpoints. We added that JSON
File product-service, but yeah we didn't tell
them about Controllers. >> Yeah sorry startup. So let's tell them. So let's go back down. We already commented
out that stuff out. So why don't we add a controller service under the
configure services method. >> So services.add. Now, we can add the entire MVC, everything views, and controllers, and the goal kind of thing. But instead let's just
go and add controllers. You only want to add the
stuff you're going to use. >> Yeah. >> Maybe later we'll add other stuff, but for now keep it minimal. >> Keep it minimal. >> Exactly. So this is a
very common pattern here. Add stuff, and then you use stuff. >> Yeah. >> Okay? >> Yeah. So back under
the endpoints land, we're going to add another endpoint, we're going to map to our controller. >> So we're going to
say map controllers. Interesting, remember how we talked about this? Razor
pages/privacy/error. Controllers, you can't see it
but it will be slash products because we routed it as slash products because that's
the name of our controller. Again, worth pointing out, we could always say slash food
or whatever if you felt like it. >> Yeah. Now, in this case, we've been getting JSON this whole time with
this API that we made, but what if we didn't want JSON because that's a lot
like XML or something? >> That is very good
point. So right now it's assuming that I'm just going
to return a list of products, but it doesn't say as what. Do we want the ProductsController
to be responsible for that? Maybe we would want
to configure that. You have to ask yourself
is that a business problem or is that more of a
check-a-box maybe problem? You can if you want, go check out the docs and
learn about how to add XML serializers to this and teach it how to
automatically returned XML, and the cool part is no code
would change in the controller. >> That is excellent. >> Isn't that fun? Now,
do we think it will work? >> I think it'll work. >> Pressure is on, I don't know. I just hit control F5, I'm going to go ahead and run that. >> Great. >> I'm going to hit slash Products. >> Yeah. There we go. Now we're back in business. TCB. >> Yep. >> Fantastic. >> I actually don't know
what that stands for. >> Taken care of business. >> Real. >> We're TCB-ing here
doing ASP.NET core. Let's take a break
and we'll come back, and we'll extend that service with not just a Get but
with something else. >> Cool. TTYL.
