BlazingPizza: application Blazor du début à la fin. Partie 1. Configuration de l'environnement

Bonjour à tous! Si vous avez entendu parler de Blazor , mais que vous ne comprenez toujours pas ce que c'est. Vous êtes alors à l'adresse. Ceci est le premier article d'une série de 12 articles qui vous emmène à travers tous les cercles de l'enfer tout le processus de création d'une application sur Blazor . Au final, nous aurons un site prêt à l'emploi pour une petite pizzeria, assez au niveau des sites prêts à l'emploi pour certaines pizzerias. Par conséquent, vous serez fier de;)

Ce sera un peu hors de l'ordinaire HelloWorld . J'ai délibérément abordé certaines complications qu'il vaut mieux prendre immédiatement comme règles, en particulier, il s'agit d'une architecture à trois couches typique: View-Domain-DataAccess .

Je crois qu'il vaut mieux le suivre immédiatement que de montrer quelque chose d'artificiel, sans rapport avec la vie. Comme le montre la pratique, de nombreux développeurs restent bloqués au niveau de HelloWorld et utilisent ensuite ce qu'ils ont vu lors de la conception de grandes applications a priori (bonjour à mon ex-banque la plus verte du pays et à son Service.cs avec tout le code d'application dans un fichier, je ne plaisante pas).

Je vais vous dire comment mapper des données entre couches sans douleur et sans avoir besoin d'écrire de nombreuses lignes de code. Nous déploierons également le tout dans Azure DevOps. Oui, maintenant c'est une partie nécessaire de tout processus de développement, nous volons tous dans les nuages ​​aujourd'hui, certains sur site , certains dans Azure ou AWS .

De plus, pour que le premier article ne soit pas une histoire banale sur la façon de cliquer sur un bouton dans Visual Studio, puis sur un autre, j'ai pensé qu'il serait bien d'organiser un petit défi et d'essayer de faire quelque chose sur Linux pour la première fois .

Je m'attends à ce que vous ayez une connaissance minimale d'ASP.NET, C #. Bien que ce soit HelloWorld, je ne parlerai pas de ce qu'est Program.cs.

Ensuite, nous discutons de ce qui est nécessaire pour la programmation sous Linux .
Attention: Dans les deux paragraphes suivants, mon impression est reçue d'un vrai travail avec Linux, qui l'a installé dans les meilleures intentions, si Linux vous donne des sentiments enthousiastes et que vous ne pouvez pas vivre un seul jour sans ouvrir la ligne de commande, alors vous pouvez ruiner votre humeur, Continuant à lire cet article!

Distribution: Ubuntu


En vérité, vous ne serez pas à l'aise avec la programmation sous Linux, mais si vous voulez vous concentrer sur les affaires, installez Ubuntu 19.10 . J'ai réussi à le mettre la deuxième fois, c'est bien qu'au moins la deuxième fois. Et toutes les équipes ont terminé la première fois, presque toutes. Je déconseille fortement d'installer toute autre distribution, j'ai passé toute la journée à configurer le dernier OpenSuse , puis je l'ai démoli.

Pourquoi avez-vous même besoin de développer sous Linux ? Eh bien, au moins parce que .Net Core le prend en charge et peut-être que votre employeur décidera d'économiser de l'argent et d'exécuter tout sur Linux sur la prod. Et à mon avis, l'écriture est meilleure sous le système d'exploitation sur lequel votre application s'exécutera réellement.

Gagnant IDE: Rider


Comme je l'ai dit, il n'est toujours pas possible d'écrire confortablement sous Linux ; pour tous les maux, choisissons le plus petit, Rider.

En plus de cela, il existe également deux IDE plus populaires , tels que les éditeurs de texte MonoDevelop et Visual Studio Code . Je vais vous expliquer plus en détail les inconvénients de chaque solution.

Monodéveloppement


Le plus mignon des trois éditeurs. Polices lisibles (les polices de faible qualité sont la première chose qui attirera votre attention lors du passage à Linux). Mais malheureusement, derrière le magnifique shell, il y a un vide, malgré les .Net Core 2.1 et 3.1 installés , MonoDevelop a constamment créé ConsoleApplication pour moi avec la cible .Net Core 1.1. Blazor n'a pas réussi à créer le projet, ni à lancer celui créé manuellement.

Code Visual Studio


À proprement parler, ce n'est pas un IDE , c'est un éditeur de texte avec mise en évidence de la syntaxe et capacité de construction. Parmi les avantages de la 3e ou 4e tentative, VS Code a miraculeusement lancé le projet WebAssembly que j'ai créé lorsque MonoDevelop et Rider ont refusé de le faire. C'est un plus. J'énumère plus loin les inconvénients: une police par défaut illisible et petite, je pense qu'après quelques mois de travail régulier, vos yeux deviendront tout simplement fous.

Le prochain inconvénient découle du fait qu'il s'agit d'un éditeur de texte, une action aussi simple que renommer, déplacer des projets? Tout ce que Visual Studio fait automatiquement, et nous le tenons pour acquis, se fait manuellement ici.

Cavalier


Tout est bien mieux ici que les camarades ci-dessus, Rider a même récupéré le modèle que j'ai installé pour Blazor WebAssembly . Et il a même créé une application, mais pour une raison quelconque, cet IDE a refusé de la lancer. Par souci d'équité, le serveur Blazor s'est assemblé et a démarré sans aucun problème. Rider vous permet

également d'ajouter un référentiel lors de la création d'un projet git. Mais en même temps, .gitignore s'est avéré en quelque sorte vide. Autrement dit, une intervention manuelle est nécessaire, et Rider, juste au cas où, je vous le rappelle, est en concurrence avec VS et JetBrains

prend de l'argent pour son produit. Eh bien, et comme d'habitude le problème, en général sous Linux, en principe, ce sont de mauvaises polices, elles sont très fines, mal lisibles. Les éléments sont également tous petits, ils doivent encore être ciblés. De plus, à plusieurs reprises, en deux jours de travail, Rider a suspendu le système lors du chargement d'une solution simple. L'ordinateur a dû être redémarré avec une réinitialisation, ce qui bien sûr n'est pas bon (mise à jour: au moment où cet article a été écrit, cela s'était déjà produit cinq fois).

Gagnant de la nomination Meilleur IDE C # pour Linux :
Rider - malgré toutes les lacunes, j'ai réussi à assurer que cet IDE se réunissait et lancait le projet de manière cohérente, encore une fois, pour une raison quelconque, le navigateur ne démarre pas par défaut, cela doit être fait manuellement.

Ci-dessous dans la capture d'écran, Rider (faites attention aux polices) et une tentative d'exécution du projet Blazor WebAssembly , créé par lui-même, avec MonoDevelop une situation similaire.



Si tout va si mal, pourquoi utiliser Linux ?


Permettez-moi de vous rappeler qu'il s'agit d'un projet de formation, le but était de montrer que vous pouvez toujours travailler sur Linux.

De plus, l'imperfection des outils de développement pour Linux nous pousse à de nombreuses actions manuelles qui nous permettront d'en apprendre un peu plus sur le fonctionnement de .Net sous le capot et de comprendre le travail que Visual Studio fait pour nous.

Que voulons-nous obtenir?


Au final, on obtient une jolie application, comme dans l'exemple ci-dessous:



Et maintenant pour le cas. Commençons par installer .Net Core 3.1

Installez .Net Core 3.1


.Net Core 3.1.1 SDK est la dernière version disponible du SDK , elle est disponible dans le référentiel Ubuntu . Blazor change très rapidement, donc, pour travailler avec Blazor WebAssembly, utilisez 3.1.1, la dernière version stable.

Tout d'abord, nous devons enregistrer la clé Microsoft et leur référentiel, cela se fait avec les commandes suivantes dans l'application Terminal (cliquez sur le bouton Win et entrez Term , il devrait apparaître dans la liste des celles disponibles):



  1. wget -q https://packages.microsoft.com/config/ubuntu/19.10/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  2. sudo dpkg -i packages-microsoft-prod.deb

Allez maintenant directement à l'installation du SDK .Net Core:

  1. sudo apt-get update
  2. sudo apt-get install apt-transport-https
  3. sudo apt-get update
  4. sudo apt-get install dotnet-sdk-3.1

Installer le modèle Blazor WebAssembly


Une fois l'installation de .Net Core terminée, vous devez maintenant installer le modèle Blazor WebAssembly , que je vous rappellerai alors qu'il se trouve dans la phase de prévisualisation à partir de laquelle il sera publié immédiatement en mai. Juste la veille du jour où j'ai commencé à écrire l'article, la version mise à jour 3.2.0-preview1.20073.1 (h) a été publiée le 28 janvier.

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.2.0-preview1.20073.1

Installation de Git


Si vous n'avez toujours pas installé Git , il est temps de le faire. A strictement parler, la première commande n'est pas du tout nécessaire, Ubuntu vous demandera de saisir un mot de passe, si des privilèges sont nécessaires pour exécuter la commande, nous l'anticiperons =):

  1. sudo su
  2. add-apt-repository ppa:git-core/ppa
  3. apt update; apt install git

Ce n'est pas tout, Blazor utilise Mono lorsqu'il est exécuté dans le navigateur , ce qui signifie que nous devons également l'installer.

Installation mono


Tout d'abord, ajoutez les référentiels Mono au système:

  1. sudo apt install gnupg ca-certificates
  2. sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
  3. echo "deb https://download.mono-project.com/repo/ubuntu stable-bionic main" | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
  4. sudo apt update

Installez maintenant directement Mono lui - même :

sudo apt install mono-complete

Il s'agit d'un processus rapide qui a pris environ 10 minutes sur mon ordinateur portable avec un processeur Core-i5 6200U, car la compilation source a lieu directement sur votre ordinateur.

Toutes nos félicitations! Nous avons installé tout ce dont vous avez besoin pour développer des projets Blazor WebAssembly.
Vous pouvez maintenant accéder directement au projet lui-même.

Mais avant cela, prenez une pause pour entrer des commandes et actualisez en mémoire ce qu'est Blazor WebAssembly.

Blazor WebAssembly et ce avec quoi il est mangé


Blazor est un framework web conçu pour s'exécuter soit du côté client dans le navigateur via la technologie WebAssembly (en utilisant le runtime .Net , ou plutôt des implémentations Mono , qui récemment, grâce à l'ouverture des sources .Net, n'est presque pas différent de la plateforme d'origine), ou du côté serveur avec l'hébergement dans l'application Asp.Net Core et l'échange de données via la technologie SignalR (via la création de connexions Circuits ).

Comme vous pouvez le voir dans la description ci-dessus, implémentation Blazor! = .Net WebAssembly.
Si vous jetez WebAssembly hors de ce bundle , vous pouvez développer une application Blazor Server et cela fonctionnera même dans IE 11qui n'a jamais entendu parler de la technologie moderne et Dieu merci, il n'entendra plus jamais.

Puisque nous faisons une application basée sur l'approche Blazor WebAssembly . Ensuite, nous y réfléchirons un peu plus.

  1. index.html app, . blazor.webassembly.js . Blazor , ( AutoMapper, AutoFac) Mono .

    Blazor , .

    Blazor(3.1.0-preview4.19579.2, ) .Net, Blazor, .

    Blazor , , , .
  2. Peut-être que le principal inconvénient de cette approche est un débogage compliqué, vous ne pouvez pas définir de points d'arrêt, vous n'y tomberez tout simplement pas, bien que je pense que cela soit temporaire, car il était possible de se connecter à IE et de déboguer du code JS plus tôt dans le studio .

    Eh bien, le deuxième inconvénient évident est peut-être la nécessité de télécharger toutes les sources, encore une fois, je pense qu'il existe de nombreuses possibilités d'optimisation.
  3. En fait, après le téléchargement et tous les processus préparatoires, notre application s'exécute dans le flux d' interface utilisateur du navigateur et commence son exécution. Vous pouvez appeler n'importe quel code JS à partir de C # et vice versa.

Il n'y a pas eu de photos depuis longtemps, alors en voici une ci-dessous :)



Utilitaire Dotnet


De plus, nous utiliserons activement l'utilitaire du .Net Core SDK - dotnet.

Cela vous permet de faire beaucoup de choses utiles, nous ne sommes intéressés que par quelques-unes:

dotnet build 

La commande ci-dessus recueille la solution, si vous démarrez à partir du dossier contenant la solution, aucun argument n'est requis.

dotnet new blazorwasm -ho -o BlazingPizza

Il vous permet de créer un nouveau projet basé sur le modèle qui vient après le mot nouveau, dans notre cas c'est blazorwasm , ici par exemple vous pouvez spécifier classlib ou console .

Voici les paramètres spécifiques du modèle, dans ce cas -ho , ce paramètre indique que notre application sera hébergée côté serveur dans l' application ASP.NET Core , également .Net créera des contrôleurs pour nous, que nous pouvons en particulier utiliser ensuite pour créer API Web et y accéder non seulement à partir de l'application Blazor, mais aussi à partir d'autres clients.

La dernière option -o indique le dossier dans lequel la solution créée sera placée, par défaut, c'est le répertoire courant.

dotnet run 

Une autre équipe utile, comme son nom l'indique, lance notre application.

Création de projet


Nous exécuterons donc l'équipe familière pour générer notre solution. Pour cela, sélectionnez un endroit que vous connaissez, par exemple, le dossier RiderProjects que l' IDE Rider a créé et qui se trouve sur le chemin / home / {userName}:

dotnet new blazorwasm -ho -o BlazingPizza


Après la création, nous allons construire le projet et enfin l'exécuter pour apprécier le type de résultat (la première commande est exécutée au niveau du fichier BlazingPizza.sln):

dotnet build


Tout aurait dû se passer sans problème, allez dans le dossier Serveur et exécutez:

dotnet run


Et enfin, nous voyons le résultat chéri:



génial, tout fonctionne. Maintenant, n'oublions pas longtemps l'apparence du site et passons à son contenu.

Le résultat de la première commande (dotnet new) était une telle structure de dossiers: à



mon avis, ce n'est pas un bon schéma, il vaut mieux si les dossiers ont un préfixe avec le nom de la solution, c'est plus familier (c'est ce que fait VisaulStudio lors de la création de nouveaux projets) et le rendra clair une sorte d'ext. dossier de service. Au fil du temps, le projet peut devenir un grand nombre de dossiers qui ne contiennent pas de code C # , et si vous allez dans l' Explorateur , il sera difficile de naviguer où quoi, en plus, il peut y avoir du déploiementdes scripts basés sur le fait que dans chaque dossier dont le nom commence par le nom de la solution, le projet est localisé, c'est normal, car c'est le comportement à long terme de Visual Studio et vous pouvez vous y fier.

Et donc nous renommons les projets et dossiers existants qui les contiennent (jusqu'à présent, nous ne savons rien de l' IDE , nous sommes sur Linux , et pour la première fois cela n'aidera pas, car les dossiers et projets sont nommés différemment):

Client => BlazingPizza.Client
Server => BlazingPizza.Server
Shared => BlazingPizza.Shared Les

modifications correspondantes doivent être affichées dans le fichier de solution BlazingPizza.sln . Lorsque le chemin d'accès au projet «[Serveur] \ ~» est indiqué et ci-dessous, nous le remplacerons en conséquence par"BlazingPizza. [Server] \ ~" comme dans la capture d'écran ci-dessous:



Faisons des changements similaires dans le fichier BlazingPizza.Server.csproj:



Et enfin, BlazingPizza.Client.csproj devrait ressembler à la capture d'écran ci-dessous:



Avec les modifications pour l'instant, nous en avons assez il y en a suffisamment accumulé qu'il serait dommage de perdre. Nous allons donc connecter un système de contrôle de version à notre solution. Pour ce faire, ouvrez enfin notre IDE Rider et nos solutions, ici tout est le même que dans Visual Studio, vous pouvez l'ouvrir en sélectionnant un fichier de solution.

Une fois que tout est chargé, allez dans le menu VCS => Activer l'intégration du contrôle de version . Et ici, nous connectons Git. Rider ajoutera des fichiers de service au dossier avec la solution et mettra en surbrillance tous les fichiers en rouge, ce qui signifie que ces fichiers ne sont pas corrigés dans le système de contrôle de version.
La première fois que Rider proposera de valider tout ce qui est dans le projet, y compris le contenu des dossiers bin et obj , nous n'en avons certainement pas besoin, tout cela parce que le fichier .gitignore qui a été ajouté par défaut est vide. Déplacez- le au niveau racine avec le fichier BlazingPizza.sln et remplacez son contenu par le contenu sous le kata.

Le contenu du fichier .gitignore
# Default ignored files
/workspace.xml
## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.
##
## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

# User-specific files
*.suo
*.user
*.userosscache
*.sln.docstates

# User-specific files (MonoDevelop/Xamarin Studio)
*.userprefs

# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/

# Visual Studio 2015/2017 cache/options directory
.vs/
# Uncomment if you have tasks that create the project's static files in wwwroot
#wwwroot/

# Visual Studio 2017 auto generated files
Generated\ Files/

# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*

# NUNIT
*.VisualState.xml
TestResult.xml

# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c

# Benchmark Results
BenchmarkDotNet.Artifacts/

# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/
**/Properties/launchSettings.json

# StyleCop
StyleCopReport.xml

# Files built by Visual Studio
*_i.c
*_p.c
*_i.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc

# Chutzpah Test files
_Chutzpah*

# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opendb
*.opensdf
*.sdf
*.cachefile
*.VC.db
*.VC.VC.opendb

# Visual Studio profiler
*.psess
*.vsp
*.vspx
*.sap

# Visual Studio Trace Files
*.e2e

# TFS 2012 Local Workspace
$tf/

# Guidance Automation Toolkit
*.gpState

# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

# JustCode is a .NET coding add-in
.JustCode

# TeamCity is a build add-in
_TeamCity*

# DotCover is a Code Coverage Tool
*.dotCover

# AxoCover is a Code Coverage Tool
.axoCover/*
!.axoCover/settings.json

# Visual Studio code coverage results
*.coverage
*.coveragexml

# NCrunch
_NCrunch_*
.*crunch*.local.xml
nCrunchTemp_*

# MightyMoose
*.mm.*
AutoTest.Net/

# Web workbench (sass)
.sass-cache/

# Installshield output folder
[Ee]xpress/

# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html

# Click-Once directory
publish/

# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
# Note: Comment the next line if you want to checkin your web deploy settings,
# but database connection strings (with potential passwords) will be unencrypted
*.pubxml
*.publishproj

# Microsoft Azure Web App publish settings. Comment the next line if you want to
# checkin your Azure Web App publish settings, but sensitive information contained
# in these scripts will be unencrypted
PublishScripts/

# NuGet Packages
*.nupkg
# The packages folder can be ignored because of Package Restore
**/[Pp]ackages/*
# except build/, which is used as an MSBuild target.
!**/[Pp]ackages/build/
# Uncomment if necessary however generally it will be regenerated when needed
#!**/[Pp]ackages/repositories.config
# NuGet v3's project.json files produces more ignorable files
*.nuget.props
*.nuget.targets

# Microsoft Azure Build Output
csx/
*.build.csdef

# Microsoft Azure Emulator
ecf/
rcf/

# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx

# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!*.[Cc]ache/

# Others
ClientBin/
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.jfm
*.pfx
*.publishsettings
orleans.codegen.cs

# Including strong name files can present a security risk 
# (https://github.com/github/gitignore/pull/2483#issue-259490424)
#*.snk

# Since there are multiple workflows, uncomment next line to ignore bower_components
# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622)
#bower_components/

# RIA/Silverlight projects
Generated_Code/

# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm
ServiceFabricBackup/
*.rptproj.bak

# SQL Server files
*.mdf
*.ldf
*.ndf

# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings
*.rptproj.rsuser

# Microsoft Fakes
FakesAssemblies/

# GhostDoc plugin setting file
*.GhostDoc.xml

# Node.js Tools for Visual Studio
.ntvs_analysis.dat
node_modules/

# Visual Studio 6 build log
*.plg

# Visual Studio 6 workspace options file
*.opt

# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
*.vbw

# Visual Studio LightSwitch build output
**/*.HTMLClient/GeneratedArtifacts
**/*.DesktopClient/GeneratedArtifacts
**/*.DesktopClient/ModelManifest.xml
**/*.Server/GeneratedArtifacts
**/*.Server/ModelManifest.xml
_Pvt_Extensions

# Paket dependency manager
.paket/paket.exe
paket-files/

# FAKE - F# Make
.fake/

# JetBrains Rider
.idea/
*.sln.iml

# CodeRush
.cr/

# Python Tools for Visual Studio (PTVS)
__pycache__/
*.pyc

# Cake - Uncomment if you are using it
# tools/**
# !tools/packages.config

# Tabs Studio
*.tss

# Telerik's JustMock configuration file
*.jmconfig

# BizTalk build output
*.btp.cs
*.btm.cs
*.odx.cs
*.xsd.cs

# OpenCover UI analysis results
OpenCover/

# Azure Stream Analytics local run output 
ASALocalRun/

# MSBuild Binary and Structured Log
*.binlog

# NVidia Nsight GPU debugger configuration file
*.nvuser

# MFractors (Xamarin productivity tool) working folder 
.mfractor/

# sqlite
*.db

# Don't ignore server launchSettings.json. We need a specific port number for auth to work.
!**/BlazingPizza.Server/Properties/launchSettings.json


Après cela, le nombre de fichiers non validés devra fortement diminuer à 31.

Créez notre premier commit sur l'onglet Repository:



Entrez le commit initial dans la description du commit et incluez tous les fichiers dans le commit en cliquant sur «Fichiers non versionnés» => «Ajouter au VCS» :



C l'infrastructure est plus ou moins prête, parlons un peu du contenu de la solution.

Contenu de la solution


BlazingPizza.ClientUI . Startup.cs < pp > . App.razor < pp > index.html .
wwwroot/index.html — , html c < app > .
_framework/blazor.webassembly.js .Net , Mono . .
BlazingPizza.Server
blazorwasm -ho, “Hosted deployment with ASP.NET Core – ASP.NET Core . dotnet -ho , web api. , , , - . Standalone hosting IIS, .
BlazingPizza.Shared( BlazingPizza.DomainModels)
. . , .

: Pizza, , . , - - property. , JavaScript Kotlin.

Renommez le projet BlazingPizza.Shared maintenant en BlazingPizza.DomainModels . Ici, il faut dire que Rider, malgré la note expérimentale, a fait un excellent travail. Exécutez le projet et assurez-vous que tout fonctionne et que rien n'est cassé.



Ce serait bien de créer un commit avec des modifications, ne serait-ce que pour voir combien Rider a fait pour nous, permettez-moi de vous rappeler que si c'était Visual Studio Code , vous devriez faire tout cela avec des stylos vous-même, regardez les fichiers diff en cliquant dessus.



Ajouter de nouveaux projets


Ajoutez quelques projets supplémentaires, commencez par BlazingPizza.ViewModels . Il affichera les modèles d'affichage sur le client. Pour ajouter, faites un clic droit sur la solution et sélectionnez Ajouter => Nouveau projet (le type de projet dans celui-ci et dans le suivant dans cette partie de la bibliothèque de classes )


BlazingPizza.DataAccess.ModelsModèles utilisés dans la couche pour accéder aux données de la base de données
BlazingPizza.DataAccess.InfrastructureTout ce qui est responsable de l'interaction avec la base de données
BlazingPizza.Services.InterfacesLes interfaces pour les services sont séparées des implémentations de sorte que si vous utilisez d'autres implémentations que celles par défaut, il n'est pas nécessaire de les faire glisser avec vous.
BlazingPizza.ServicesMise en œuvre de services, par exemple, PizzaService , qui ajoutera de la pizza à la base de données tout en effectuant une sorte de vérification liée à la logique métier.

Si quelque chose a mal tourné, ou si vous ne voulez tout simplement pas perdre de temps à configurer et à démarrer immédiatement après la deuxième leçon, la source est ici .

Oh oui, j'ai presque oublié :) Lien vers le projet d'origine (licence MIT) .

Source: https://habr.com/ru/post/undefined/


All Articles