Hey, everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark and this is episode
number 33. And today I am joined by Mike Brynd, the author of the upcoming Manning book,
Razor Pages in Action. And it's Razor Pages that we'll be chatting about today. So welcome
to the show, Mike.
Hi, Dan.
Hi. So when I said the upcoming book then, I guess this is actually Manning's Meep
programme, which stands for Manning Early Access programme. So it's readable straight away.
And according to the website, you're currently 10 out of 14 chapters in. So it sounds like
you're getting close.
I've almost finished writing the last chapter. The way that Manning operate their meeps is
that they'll release chapters on a sort of semi regular schedule so that there's 11,
12 and 13 have been written and reviewed. And I guess they'll release those over the
sort of next six to eight weeks, a regular interval. And then I'm just looking forward
to putting the final full point at the end of chapter 14. So that'll be the end of the
book.
Everyone has speak to that's written a book says they didn't appreciate how much work
goes into writing a book. Is that something you found?
I'm a little bit stupid in that I did know because I wrote a book about 10 years ago,
but I think 10 years is a long period and you tend to forget.
Is that like having a baby? You forget how buddy this, then you have another one.
I lost my wife, but I'm pretty sure the analogy holds. But yeah, no, I wrote for a different
publisher, the first book, and they had a different approach. Manning have a particular
way that they want you to write the book. They have a very sort of formidable style
guide to get through and so on. And yeah, to me, that's the more difficult part in terms
of actually writing. I'm happy with that. I have Chris Stisane that that was a bit
he struggled with. And I thought you poor thing because that's the bit I find easy.
But yes, it is hard work.
But it ultimately is rewarding.
There's stuff I learnt about razor pages that I thought I knew and I didn't understand
properly. But that's all part of the process as well. You do a lot of research and you
have to double check what you're going to write to make sure that you have got it right.
So yeah, it's rewarding. But yeah, absolutely. It's hard work. I mean, it's a year of evenings
and weekends and early mornings, really. That's basically what it's taken.
Yeah, I think that's what a lot of people say. And you mentioned Chris Stisane. He was
saying that he was just getting up really early every morning and that was the time he
would do his writing.
So Manning have actually very kindly agreed to give a copy away of your book to one of
the lucky listeners. And also they've given all of our listeners a coupon code to get
35% discount off any of their books. And that is podunhandle21. So any of our listeners
can use that to get 35% discount code. And near the end of the episode, we'll be doing
a giveaway for a copy of Mike's book. And that's in the ebook format.
So before we delve into reservoirs, could you give our listeners a quick intro into the other stuff
that you're working on and your background and what is you do?
Sure. I'm a late cometer programming. I spent the first 20 years or so of my working life
selling advertising space and managing teams who publish train tech magazines.
So that's my background. I got involved in programming when I was asked to manage the commercial
side of all the fantastic websites that the publishing company were launching back at the late
1990s, early 2000s, and the inner geek took over.
And that was all around the time of the first dot com bubble that burst.
And there was some reorganisation within the company I worked for.
And I started working for a division that did direct marketing for customers.
And the first thing they did, which was probably the worst thing from their point of view,
is they sent me on a course to learn the basics of development with access.
That's when I realised that databases hooked together with HTML could do something.
So I taught myself classic ASP.
So that's where I started.
And yeah, I think it took about two or three years before I became a full time developer for the company.
I like your phrase, the inner geek took over.
That's one thing I love about software development.
There's just so much stuff to play with.
Yeah, I think it is.
I felt an awful lot more at home with code doing what I wanted it to them.
People not doing what I wanted them to do.
And I was trying to sell stuff to them.
And never really understanding why it is that, you know, my my logical pitch wasn't hitting home at all.
Unfortunately, I've found that that problem doesn't go away.
No, no, no.
No, I'm a lot more comfortable with why why it doesn't work like that.
And you tend to think that people are logical and then eventually the penny drops and you work out that they're not quite often.
So that's that's what I do.
I work for a publishing company.
I manage the public facing websites, which we got a range of professional magazines
that target a couple of sectors and a number of internal applications
for managing the sort of orders, sales, production of the magazines.
And that's it really.
Nice, nice.
And you've recovered from using Classic SP as well.
I haven't I haven't.
No, I still occasionally have to look at a Classic SP app.
And it's a bit of a jolt when you go back to VB script.
But I do have one last outline Classic SP app,
which I'm hoping to kill off in the next couple of months and replace it with a dot net.
I've just got to persuade the users to move away from it.
That's that's my problem.
Ça me sent nice when you jump from doing a bit of that to doing some razor pages.
Yeah, the combination of tech I'm working with, mainly at the moment,
is I've got the biggest app is an NBC five app,
but all the new apps currently are being built with razor pages.
That might change.
I might be looking at blazer soon.
Oh, yes, yes.
Oh, I'm sure we'll talk about that in this episode as well.
So before we dig into razor pages,
I'm just going to do this episode's listener mention.
And this one goes out to Houston Haynes,
who on Twitter said, enjoyed an exceptional unhandled exception podcast
yesterday, Dan and Chris cover a wide range of topics,
mass transit, the OSS landscape
and how certain tech is ill fitted to message queuing
and is putting buckets Kafka.
I'm not sure that's quite what we meant, but never mind.
And he also said on high firing over JetBrains rider.
We definitely did a lot of that.
So thank you, Houston.
And if you want to get mentioned on the show,
just send a tweet using hashtag unhandled exception.
All feedback is greatly appreciated.
And I'm dracon on Twitter, D R A C A N.
So razor pages.
So ASP.net has quite a few different flavors.
And I'm thinking MVC,
which you've already mentioned razor pages and blazer,
which you just mentioned as well.
So before we dig in and talk about actually building sites
with razor pages, could we start off by talking about
when you choose razor pages over MVC or blazer?
Yeah, sure.
Razor pages,
I would use that for any website
that you want to build where the HTML
has been generated on the server.
In fact, I probably wouldn't use MVC
for that at all nowadays.
The reason for that is one of the reasons
why razor pages was introduced
was it was intended to make developing
server side applications a lot easier
than using the traditional MVC framework
that Microsoft introduced back in 2008
or nine or whenever that was.
Because one of the things with the MVC pattern
or the implementation that Microsoft
have put in place with ASP.net
is it uses what I would describe
as a from controller approach.
Each controller is normally sort of grouped together
by as under an entity such as a product or customer.
And they can be responsible for large numbers of endpoints.
And so you end up with classes
that just grow and grow and grow.
And I've got in classic MVC5 applications,
I've got controller classes that can exceed
sort of 5, 6, 700 lines.
I've seen them with more.
And as the application grows,
so does your controller class.
Well, that's not that easy to manage.
And you also have to work with the convention
of placing your stuff into folders
called model, a view, and controller.
And if you don't, if you try to fight
against that convention,
the tooling sort of starts to get a little bit ropey.
It doesn't work as well.
With difference between that and razor pages,
razor pages adopts what I would call
a page controller approach to the same MVC pattern
in that your view is still separated from the controller
and that's separated from the application model.
But each, because each controller is responsible
just for managing the inputs for a particular page,
they necessarily are a lot smaller.
You get a lot more of them,
but they're a lot smaller
and they're a lot easier to manage.
Yeah, I find very similar working with Web API.
So I do a lot of API work.
And having controllers,
like you've still got the controllers in Web API.
And I find that when you have,
especially when doing rest stuff,
so you've got get post-delete
and you might be doing depends injection,
injecting lots of things,
then it can get, as you say,
one controller can get quite big.
So I kind of like the mediator pattern
where you've actually got a mediator handler
which kind of gets around that.
But yeah, totally with the,
you mentioned about the forced folder structure,
having explicit models, views folder,
and then controllers.
When Chris Enti was on talking about Blazor,
he was talking a lot about feature folders.
And instead of having these folders
that are implementation detail,
is it a view, is it a controller?
Then instead having a directory
that says what the feature is.
And that sounds kind of like
Razor pages would give you that almost.
It does absolutely, yeah.
And I totally get what Chris was saying.
If you try to introduce features folder
into sort of traditional MVC5 app,
the first thing you have to do
is to fight against the frame rate
so that it knows where to look for the files
because it's trying to look in a views folder.
And then when you start to use the scaffolding
to create stuff,
you get all sorts of issues.
It tries to tell you
or you've got a views folder,
it hasn't got one.
And you don't want it in the views folder.
But feature folders,
yeah, because the routing in Razor pages
is so simple, it's based on file location.
You get feature folders
just by adding a folder
with the feature name on it.
It's magic.
You don't have to start fighting against
any of the routing conventions or anything.
It just works.
Yeah, it does seem really nice
just having that right at the top.
You go to your view
and you can see all the information
you need at the top of the file.
And then you've got your HTML
and it does seem quite clean.
Regarding putting like the...
I know this is probably
a bit like asking someone
whether they like tabs versus spaces.
But the whole putting code
within the Razor page
versus putting code
in like a code behind file
or the Razor page's equivalent.
Do you find that one's better than the other?
Or does it depend?
Oh, non,
je ne dirais pas qu'on a pas
le code application
dans le file Razor.
Le class de la page model
et le code behind, si vous voulez,
sont très bons.
En même manière,
le contrôle est dans la
traditionnelle MBC.
Ça vous aide à séparer
votre code application
du HTML.
Je le vois dans le book de Chris Sainte
et il parle de la façon
qu'il préfère approcher
les compagnons
où il préfère pas
utiliser l'option
de la code behind
pour un component.
Et il va avoir son code
dans un bloc de fonction
dans un component.
Donc, sa approche
avec Blazer
est complètement différente
de ce que je recommande
pour les pages Razor,
qui est intéressant
et quelque chose que je vais explorer.
Oui, le modèle de page
classé dans les pages Razor
est juste comme
c'est similaire à un contrôle
dans lequel c'est testable.
Mais aussi, vous devriez
minimiser
l'application de code.
Vous avez des
handelons
dans le modèle de page
qui répondent
aux verbes de l'HTTB.
Donc, vous avez des requests
sur le get
et le poste
va prendre
l'accessibilisation
pour un poste.
Ça marche par convention.
Mais,
il y a des logiciels compliqués
qui doivent être séparés
dans un autre modèle.
Comment vous le faites?
C'est vraiment up to you, je pense.
Je pense que c'est bon
d'avoir l'application
de logiciel business
séparé
du modèle de vue, je pense.
Et par modèle de vue,
je veux dire
un code qui est
très proche de ce que le vue est.
Donc, si un bouton s'est pressé,
c'est ce que vous avez fait.
Mais oui, absolument,
je suis certain que je serai
en train de faire
une logique business
séparée.
Le riz,
c'est une partie
de la combination.
La seule logique
qui doit être
de la présentation.
Et
peut-être formuler
le contenu,
de l'application,
de l'application.
Si vous avez
quelque chose de plus compliqué,
alors ça devrait être
un truc de plus.
Ce qui est justement validé
pour les apps
aussi.
Vous allez utiliser des helpers
ou des fonctions
séparées
qui peuvent
encore utiliser
les helpers HTML
si vous voulez.
Mais les helpers
préférés.
Oui, c'est bon
de parler de ça.
Juste avec
la toute
la code en
le code derrière
dans les bits de plays
que je fais de l'an dernier,
un issue
où je mets
en code, en fait,
dans le component
était
pour la code C.
Je suis en fait
4 spécifiques
pour ma indentation.
Et en HTML,
je suis en 2.
Et je suis en le même file
avec le même file extension.
Je l'ai mis
dans le code.
C'était un peu de pain.
Donc, pour moi,
c'est une raison
pour le mettre dans un autre file.
En tout cas,
ça ressemble un peu à un peu de chier.
Oh non,
je comprends pas
ce que ça résonne
avec moi très bien,
d'ailleurs.
La autre chose que j'ai trouvé
est que
si vous n'êtes pas
au courant
des raisons
intelligents
et format,
vous pouvez avoir un peu de rôpé.
Oui.
Je suis en train
de faire
peut-être pas beaucoup maintenant
parce que je pense que le blazer
est un peu plus stable.
Mais en les jours avant,
avec l'intelligence et ce genre de choses,
il y a des warnings
où il n'était pas
trop négocié.
Mais je pense que maintenant
il se trouve beaucoup plus stable.
Donc, j'ai vraiment, vraiment
aimé le blazer.
Vous faites beaucoup de blazers,
tout ça?
Pas beaucoup.
Je suis en train de faire
des projets
et je travaille sur
des blazers qui sont
en train d'arriver.
Mais je suis un peu
un peu de maître
que je fais en ce moment.
Il y a beaucoup de
API,
des choses qui sont
de la Kubernetes,
comme je dis,
il y a des blazers
qui sont en train d'arriver.
Pour un projet,
je suis en train de jouer
avec Maui,
qui est encore en prévu.
Oui.
Mais, encore,
c'est ce que nous avons
décrit là
parce que c'est
un jour plus tard.
Je vois beaucoup d'id
des issues
où les warnings
et ce genre de choses,
c'est pas un warning
ou l'intelligence n'est pas
travaillée correctement.
Mais c'est prévu,
donc je ne peux pas
vraiment compléter trop.
C'est bien que
maintenant les choses sont
en train d'être
réellement réellement
c'est bien que nous
on a des opportunités
pour jouer avec ça
plus tard.
Oui, c'est un peu différent
de ce que j'ai été
en France,
en fin de jour,
quand on a été
en France pour
répondre aux questions
et des questions techniques.
Mais oui,
je me souviens
quand l'esp.net
web pages
de la chaine
était launchée
et nous avons appris
ceci
dans des meetings
qui se passent
peut-être
tous les deux mois.
Et nous avons découvert
ce que nous avons fait
et il n'y avait pas
un grand nombre
d'encourages
pour le feedback.
Mais ils ont
pensé
qu'ils ne faisaient pas
pas d'input
dans la direction
ou quelque chose comme ça.
C'est intéressant
comment les programmes
de l'NVP ont changé
aussi
avec l'open source.
Oui, je pense que tout a changé.
Les programmes de l'NVP
ont changé,
le .net
a complètement changé.
Il serait intéressant
d'avoir un épisode
sur Microsoft's journey
avec le .net
de s'envoyer
une source de closures
pour
voir ce qu'il y a maintenant
envers l'open source
et
cross-platformer
et tout ce genre de choses.
C'est une excellente route.
Oui, il y a quelques personnages
qui sont encore sur Microsoft
qui pourraient probablement
parler
tout de l'heure
sur les premiers
les premiers des pièces
de cette particulare route.
Pas beaucoup
ont été
déménagés
depuis
10, 12 ans
quand il a commencé.
Je me suis bien regardé
Richard Campbell
de .net Rocks.
Il a
travaillé
pour un peu de temps
maintenant,
mais il devrait être
réellement
reliant,
il dit.
La histoire de .net.
Oh, vraiment?
Oui, il a été interviewé
à tant de personnes
qui ont été involveées
dans la route
d'envers
où .net a commencé
et comment il a évolué.
Oui, je pense que ça serait
vraiment, vraiment bien,
mais quand il s'en vient,
parce que je ne sais pas
si vous l'avez écouté
à .net Rocks,
mais comme des épisodes
de son geek out,
où
souvent, ils ont un épisode
où
c'est un sujet
de développement de software,
c'est juste un général
geek out de tech
ou science.
Et Richard
fait
son research.
Il a fait
beaucoup de notes
et sérieusement,
fait beaucoup de research
et il se fait vraiment
en profondeur.
Donc, si il a été
comme ça
avec son livre,
qui je suis sûr qu'il y a,
il devrait être
un livre vraiment,
je suis en train de voir.
Non, ça semble vraiment intéressant.
Donc, en regardant les pages de Razer,
je me suis souvent dit
ce terme
« Razer Components ».
Et je suis un peu confusé
par ceci,
parce que
je pense que c'est
en fait
les components de la Razer.
Et alors,
si vous utilisez les syntaxes de Razer,
vous ne pouvez pas
les utiliser dans les pages de Razer
ou vous seriez
encore néanmoins
défauts
pour quelque chose
comme des components de vue.
Je pense que vous pouvez
certainement
embedter un component de Razer
qui est
un part de la tech de Razer
dans un page de Razer.
Et ça pourrait être
utile de l'utiliser
un component de Razer
mais je pense que
si vous utilisez
un point de vue de Razer,
je serai certainement
en utilisant un component de vue.
L'un des choses que j'aime
de la Razer
c'est juste ce concept
de l'utiliser des components
comme des blocs de la construction
de votre site.
Donc, dans les pages de Razer,
fais-vous des components de vue
pour des mêmes rôles
que vous pouvez avoir
très petites
components de Razer
à travers votre application ?
Oui, oui,
absolument.
Il y a deux différents types
de la saison
de votre UI
et des pages de Razer.
L'une est de utiliser
des pages de partialité
qui sont encore
encore aussi valides
comme elles l'ont été.
Et l'autre
est de utiliser
quelques components.
Vous utilisez des components de vue
pour les zones de la UI
qui ont besoin
d'une sorte de service
comme un menu de date,
par exemple.
Vous pourriez probablement
désoigner un component de vue
et puis placer
dans votre layout
plutôt que
de l'offrir
et de l'afficher
parce que le layout
n'a pas de code
pour le layout.
Et vous ne voulez pas
vraiment être allé
en façant des données
dans un layout.
Donc, oui,
vous avez développé
des components de vue
et puis vous pliez
dans votre layout
en utilisant un aidage.
Donc, vous avez toujours
en train de penser
d'un exemple ?
Donc, si vous avez
une barbe nav
qui a une section
sur les liens sociaux,
une section
avec un peu de menu
d'items,
une section avec
un drop-down,
un peu de bits et bobs,
je pense que dans Blazer,
vous pourriez faire
chaque des components
et faire
une barbe navale
qui est assez granuleuse
et spécifique.
Vous pourriez faire
la même barbe navale
ou est-ce que ce n'est pas
vraiment un pattern
que vous pourriez
suivre les barbes navales ?
Je suppose que vous pourriez
être comme granuleuse
que vous aimez
dans un range de pages.
Je pense que vous pourriez
avoir un tout petit
composé
de des components
et des partages
si vous voulez.
Je me demande
de la complexité.
Et c'est un des choses
que je regarde
à Blazer
et voir
que
le moyen de les choses
sont lesquelles
un train
pour plus et plus
de componentisation.
Vous avez le droit
d'avoir un autre
avec quelque chose
de réacte.
Donc,
je pense que
si vous êtes venu
de cette
pratique de travail
et que Blazer
est très componentisé,
il fonctionne très bien pour vous.
Mais oui, je pense
que je vais essayer
de minimiser le nombre de files
comme possible
parce qu'il n'y a pas de
maintenance,
mais évidemment,
vous n'avez pas besoin
de la toute chose
dans une
surmodélisation
de la page ou quelque chose.
Oui, je pense que
tout ce qui est un peu
un bonheur,
c'est un peu
si vous n'avez pas
le droit de componentisation
de toutes les lines,
mais vous n'avez pas besoin
d'une surmodélisation,
comme vous le disiez.
Je pense que
l'answer est toujours
que c'est
que c'est
un bonheur.
Oui.
Je l'utilise
presque sur un basis

Oui.
Oui.
Donc, les gens qui
récompensent mon voiture.
Donc,
ça ressemble à ce
terme de componentation
un peu de la misogynomé,

parce que c'est assez
confusant
parce que
si c'est un autre
technique,
et c'est
un design pour Blazer,
je sais que c'est certainement
confusant pour moi.
Le
code de la page
des websites
des compagnons
de Blazer
sont construits
en utilisant des compagnons de Blazer
informément
les compagnons de Blazer.
Je vois que Andrew Locke,
il a écrit un
article de blog,
recommandant
que vous ne repassiez pas
vos compagnons de vue
avec des compagnons de Blazer,
même si
techniquement,
c'est possible.
C'est bien.
Je vais inclure ça
dans le show,
je vais avoir une recue
de ça.
Vous avez mentionné
avant de parler de
des helpeurs de TAG
et des helpeurs de HTML.
On peut parler un peu
d'où vous utilisez ces
helpeurs?
Oui,
je migre,
je suis sorti
dans le processus
de migrer
une app
sur les pages de Razor
et vous devez
migrer les visages,
évidemment,
et chaque vue
sera représentée
comme une seule page.
Je vais utiliser
les helpeurs de HTML
dans cette migration
parce que c'est plus rapide.
Mais si il y a de nouvelles applications
que j'ai mises ensemble,
je vais utiliser les helpeurs de TAG.
On peut parler de ce qu'ils ont
pour les listeners
qui n'ont pas vu ces
avant?
Quels helpeurs de TAG
vous parlez de?
Oui,
ou les deux.
Oui,
je pense que
la recommandation
qu'on a en ce moment
dans le UI
est maintenant de
utiliser les helpeurs de TAG
plutôt que
les helpeurs de HTML.
Les helpeurs de HTML
sont de l'ancien type de NBC
et il y aura un range
de helpeurs de HTML
pour les petits parts de l'analyse.
Vous pouvez avoir un
qui rend un input
un type texte
ou un area de texte
ou un liste de dropdown.
Il y a beaucoup de formes
de contrôle,
par exemple,
ou des anchors.
Et
dans .NET Core,
ils étaient
replacés par les helpeurs de TAG
qui font les mêmes choses.
Mais les helpeurs de TAG
utilisent un type de type de type de HTML.
Donc ils se sont naturalement
plus naturels dans un vue.
Les attributes
sur
les helpeurs de TAG
activent la code de service.
Donc
vous pouvez bind
les formes de fields, par exemple,
pour les propres sur votre
modèle de vue
qui sont partie du modèle de page.
Et
les types de HTML qui sont générés
seront automatiquement
générés par les idées
et les noms
des attributes sur
les types de type de HTML.
Par exemple.
Et ça
va aussi
bindre les valeurs
qui ont été associées
aux propres dans votre modèle de page.
Donc vous vous avez sorti
d'un type de binding de deux manches.
Parce que quand les formes sont subies
et que les valeurs sont postées
et que le binding de modèle s'accorde.
Et on va bindre
les valeurs de subie
sur les propres sur le modèle de page.
Donc
l'autre chose
sur le modèle de page de réservoir
que j'aime
est que vous n'avez pas
à créer
des classes de vue séparées.
Vous pouvez encore
mais vous avez juste
à propos de propres
de propres publics
sur votre classe de modèle de page.
Vous avez un attribute de property
à leur attribute.
Et ils vont automatiquement
se réagir
durant un poste de requêtes.
Vous pouvez aussi
les activer
pour qu'ils puissent se réagir
pendant les requêtes de réquêtes.
Certaines personnes
parlent de
les pages de réservoir
comme un
implementation
de la pattern de l'envermement.
Parce que c'est un
deux-deux bindage
entre
les propres publics
sur votre modèle de page
et les formes.
Alors
ce n'est pas probablement
le même
comme le pattern de l'observe
ou le pattern de l'envermement.
Vous pourriez normalement
voir des choses
comme des développements mobile
ou
quelque chose de knock out
ou quoi que vous.
Je l'ai mentionné
maouille et d'autres choses
comme WPF.
Les modèles de vue
qui ont besoin de meser
avec le changement de property
de l'envermement
sont tellement hauts.
Donc
je suis heureux
que ce n'est pas assez comme ça.
Non, non,
c'est juste
c'est juste une simple
simplification
de la route de la route, je pense.
C'est le moyen
que je tende à regarder de toute façon.
Mais ce n'est pas
vraiment un MbVM.
Oui, oui.
Je pense que avec le tout
parce que les tâques
helped nous
ressemblent
comme des éléments.
Vous avez
cette toute
utilisabilité
et ça justifie
bien
avec votre vue.
Et c'est juste plus consistant
pour quand le design
vient et commence
l'HTML.
Je pense que c'est le but
de ceci
comme tout le monde
est
que l'aide à la tâche
est beaucoup plus
designable
et plus
que d'un
l'aide à l'HTML.
Certainement.
En parlant de la
question
je suis toujours
un grand fan
de
test.
D'autres
tools et technologies
pour
spécialement
tester
la page de la page
par servers Ubuntu.
D'accord,















nt
Donc, oui, vous n'avez pas besoin d'avoir quelque chose spécial pour ça.
Cool, cool. Vous avez imaginé l'injection de la dépendance,
ce qui était une autre chose que je voulais vous demander.
Présumement, vous pouvez injecter la dépendance directement dans le vue.
Vous pouvez, mais généralement, vous ne pouvez pas.
Il y a des services que vous injectez directement dans le vue,
parce qu'il n'y a pas besoin d'injecter les services dans le modèle de page,
il n'y a pas besoin d'utiliser les services.
Un des exemples de ces services est le service anti-faudre.
Les services de la base, les vérifications de réquestes sont encevées par default.
Vous devez les appeler dans l'application de l'NBC, mais c'est encevée par default.
L'aide de la forme, une des encevées,
est de générer le fonds de l'antifaudre pour l'antifaudre.
Si vous n'avez pas eu une forme,
ou vous n'avez pas fait sur le format,
dans une poste de Ajax,
vous devez générer l'antifaudre pour vous-même,
ce qui peut être fait par l'anantifaudre.
Vous devez utiliser l'aide d'antifaudre,
ou vous pouvez l'injecter dans l'antifaudre,
et vous utilisez le direct de l'injecteur pour atteindre ça.
Vous pouvez utiliser le service pour générer le fonds,
et puis passer ça par votre poste de Ajax.
Je vois, je vois.
Si vous faisez un code derrière, vous utilisez la injection de la base.
Si vous faisiez un code derrière, vous faisiez juste l'injecteur à la fin.
Oui, je pense que c'est le même code que vous utilisez
dans l'injecteur de la base si vous faisiez un code derrière
pour un component de blazer.
Oui, c'est très bien et c'est clean.
Juste avoir ce metadata au-dessus,
que vous avez mentionné le route avant,
avoir le route, l'injecteur, l'entrée,
tout au-dessus, c'est partie de votre vue,
je trouve ça assez clean.
Et en mettant le template de route au-dessus de la page de la base,
oui, absolument,
oui, et ce même pattern a été fait par la base à blazer aussi.
Oui, oui, très bien, très bien.
Donc si vous avez besoin de faire un fonds,
faire des trucs frontiers,
ou des trucs clientiels en utilisant le JavaScript,
évidemment avec blazer, ce n'est pas un problème,
mais si vous le faites dans les pages de la base,
est-ce que vous avez des techniques de l'aide
pour vous permettre de faire la base de la base en partie de la base?
Vous avez fait les mêmes choses que vous avez fait si vous étiez en place de l'MBC,
oui, ce n'est pas différent,
c'est juste le JavaScript à la base de la file,
ou dans des files séparés et injectés.
C'est essentiellement le même type de vue en train de vous utiliser
un style de style de la base,
sans le dire, le code ASP.NET Core,
donc vous vous injectez dans une section normalement called Scripts.
Donc ça vous a dit avant,
que vous ne seriez pas en place de la base en partie de la base,
et que vous vous portiez à la base,
ça vous semble super simple à prendre,
vous vous injectez un app et vous convertez-le en MBC
sur Razor Pages.
Ça va.
Je ne recommande pas de migrer un app ASP.NET Core
sur Razor Pages,
je ne pense pas que c'est beaucoup à être gagné,
même si votre mileage peut changer.
Mais pour migrer un app MBC5,
le framework de foret.net sur Razor Core,
la migration des vues contrôles sur Razor Pages
n'est pas particulièrement compliquée.
Vous trouverez que vous vous mobilisez vos méthodes d'action
à travers des classes de modèles de page séparées
qui soutiennent différentes pages.
Et les vues sur les templates,
largement vous trouverez que vous pouvez les faire en arrière,
il y a un peu de tweaking,
parfois ici et là,
mais oui, vous pouvez migrer à travers
et ensuite vous vous emmettre.
Vous avez l'aide de vos helpers,
vous vous attaquez les helpers
comme vous vous aviez avance.
Mais pour une nouvelle app MBC,
vous pouvez ajouter des pages Razor,
vous vous aborder à vos appareils,
et vous avez un hybrid de pages MBC et Razor,
si vous voulez migrer à travers les pages Razor
au long terme.
Vous pouvez migrer à l'extérieur
et se convertir en application.
Vous pouvez, oui, absolument.
Très bien.
Donc, des choses comme authentification et sécurité,
etc.
Est-ce qu'ils suivent les mêmes
standards de page ASP.NET
ou est-ce qu'il y a quelque chose différent
de les pages Razor ?
Non, c'est le même framework d'identité
que vous utilisez dans l'application MBC.
Ce n'est pas en haut de la défaut,
vous vous pliez si vous avez besoin.
Vous avez les accounts organisés,
les idées traditionnelles,
les idées d'identité,
les schémas et les databases
dans le bas-de-bord.
Ou vous pouvez utiliser
la même chose
pour ajouter une troisième partie de l'authenticateur
comme Facebook,
Twitter, Google et quoi.
Donc, vous n'avez pas besoin de apprendre
quelque chose de nouveau pour ajouter
l'authentication à la page Razor
si vous êtes déjà travaillé
avec ASP.NET Core et l'identité.
Et c'est évidemment le même,
c'est vrai pour les accesses data
donc, en regardant l'entité framework,
j'utilise l'entité framework et DAPA
selon les réquivités pour l'application.
Je vais parler des applications magasines
que j'ai mis en place,
et je les read seulement.
Ils ont une application séparée
pour les contrôles.
Mais cela a été déclaré
et j'ai tendu à utiliser DAPA
parce que c'est plus rapide.
Je suis très content
avec l'authentication de Microsoft.
C'est presque un ligne
avec les libres d'identité

C'est impressionnant.
Nous avons eu Christophe Mutska
dans l'une des épisodes plus vides
et il avait parlé de cela.
Et oui, ils sont vraiment
essayés de le faire beaucoup plus facile
pour ajouter l'authentication
aux applications.
Oui, ils vous ont donné
un sample UI-package
aussi.
Vous n'aurez pas utilisé
l'application de production
mais cela certes vous donne
un bon start-up
et d'un point de vue de la classe
vous donne une bonne idée
de l'idée de la scope
des features que l'offre
l'alcool.
Oui, je pense que je vous ai mentionné
dans le livre que je n'ai pas
utilisé parce que vous avez
à déçir le tout le load.
Si vous ne voulez pas
offerter des choses
comme 2-factor authentication
et ce qui est en train de l'enlever
par default
dès que vous avez l'alcool.
Oui.
Donc, si vous avez
écrit vos expériences
et vous voulez l'ajouter
quelque part,
est-ce juste d'une poste
ou est-ce que vous avez
l'intention de l'utiliser?
C'est standard ASP.NET Core
hosté,
donc vous pouvez l'utiliser
comme un déploiement de framework
dépendant
et puis,
alors que le service target
a le bon framework sur le service,
votre application va rire.
C'est évidemment une plateforme
parce que l'alcool.NET Core
est une plateforme de passe.
Je hoste nos applications
sur un service virtuel,
un service virtuel de Windows.
Et je l'utilise
je suis toujours en état de l'alcool.
Je l'utilise à un folder local
et puis le file de remplacement
de la FTP.
La seule chose que j'ai eu,
je pense,
quand j'ai utilisé les pages de réservoir
ou en fait,
l'AISP.NET Core,
quand vous voulez faire ça,
c'est que vous devez
tourner votre application
en avant d'être
able de réoverliger les assemblages
parce qu'ils se sont faits
beaucoup par le processus,
dont vous n'avez pas été
en train de faire
la version formule
de ASP.NET.
Vous avez juste évoqué vos files
et ils ont fait
des choses dracques
avec des copies de shadow
dans le background,
c'est comme je pense
Microsoft l'a décrit.
Et c'est intéressant,
ils tentent de...
Il doit être compliqué
de quoi ils faisaient
parce que c'est en train de prendre
six ans
pour reintroduire
l'AISP.NET Core
et c'est été
expérimentalisé,
je l'ai remarqué,
pour partie de l'AISP.NET 6.
J'ai essayé,
ça semble travailler
bien avec l'application.
Comme vous avez ajouté
et puis j'ai des problèmes.
Donc,
j'ai sorti de
la file app off-line
live
sur le site
pour arrêter l'application,
copier les files
et puis
renommer la file app off-line
pour quelque chose d'autre.
C'est une force brute,
mais en regardant
les
Je pense que c'est ce que vous avez dit
l'an dernier,
c'était 10 ans plus tard,
vous l'avez dit ?
Oui,
je pense que en 10 ans,
je vais être un seen island.
J'ai oublié de l'envers.
Ouais,
ça nous fait
beaucoup d'envers pour
votre recountation
de ma sortie de Constitution
donc
vous Twist처럼

à cause de la chute
et nous avons
envoyé toutes ces
files
en mystery au fait
que l'on l'a optionné
avant.
Super,
food
pro
C'est-vous être
encore s'est envoyé ?
Oui
Cool,
on a une rencontre de

comme vous l'avez dit
à la fin de la fin, Manning a très, très kindly offert de donner un couple de votre livre.
Et aussi, comme je l'ai mentionné à la fin, ils nous ont donné un code coupon pour
que nos listeners puissent s'en aller 35% et c'est pod unhandle21.
Mais un de nos listeners peut gagner un couple de votre livre, qui est assez excitant.
Et ce que je pense que nous allons faire, c'est que si quelqu'un qui veut être inclus dans le
podcast, utilise le hashtag UnhandledException et aussi Mike's Book, et puis une semaine après
la publication, je vais prendre un à la fin et puis on va se mettre ça avec vous.
Ok, donc, on va faire des tips de la vie ?
Oui, sûr.
Mon tip est ne détenez pas de technologie, sans au moins donner un bon goût.
Et le raison pour lequel je disais ça, c'est que je vois certainement, en les
pages de la raser, que ce soit seulement suitable pour les appels simples ou une version
de la réversion de l'old webforms, parce que c'est un code derrière l'approche.
En fait, ce n'est pas ça, c'est aussi fort comme NBC.
Mais quand vous questionnez les gens de pourquoi ils avaient cette pensée sur les pages de la raser,
ils ont vécu que ils n'avaient pas donné ça à l'avant.
Donc ne détenez pas de technologie sans au moins donner un bon goût.
Le point de vue de file qui liste les files sur le gauche a une checke de la raser sur le gauche
au suivi de chaque file.
Le point de vue de file de la checke est persisté juste pour vous et c'est de marquer la file
qui est réveillée, ce qui est super utile.
C'est comme une checke de la liste de ce que vous avez réveillé en ce point.
Et je l'ai juste checké sur GitHub et ça a une similaire vue de la checke de la raser,
mais c'est un peu plus clair sur GitHub.
En Azure DevOps, ça ressemble à une de ces checke de la raser multi-select,
je n'ai pas réalisé ce que c'était avant, mais je vais commencer à utiliser la similaire
en avance.
Donc, comme je l'ai utilisé Azure DevOps pour des années et j'ai complètement détenu ça,
donc je pensais que c'était plus important de pointer ça.
Excellent.
Cool.
Donc, avant que nous nous rapprochons, où est le meilleur placeful listener pour vous
si vous avez des questions ?
Vous pouvez me dire sur Twitter,
à mike.net, c'est assez bien.
Je peux définitivement inclure un lien avec ça dans les notes de la show.
Oui, je vais avoir mon lit,
je me tend à être clair de mon public en cas de...
Je sais pas.
Je vais inclure un lien avec votre livre sur le site Manning.
Et vous me donnez un autre site qui je peux aussi le lien.
Le learnraiserpages.com.
Oui, je vais inclure un lien avec ça aussi.
Cool.
Donc, merci beaucoup d'avoir regardé, c'est bien de vous avoir regardé.
Oui, c'est mon plaisir.
Et je vais inclure les liens à tout ce qu'on a dit dans les notes de la show,
qui peuvent être trouvées sur un podcast de l'exception de l'un de l'autre.