BlazingPizza: aplicación Blazor de principio a fin. Parte 1. Configurando el medio ambiente

¡Hola a todos! Si has oído hablar de Blazor , pero aún no entiendes de qué se trata. Entonces estás en la dirección. Este es el primer artículo de una serie de 12 artículos que lo lleva a través de todos los círculos del infierno durante todo el proceso de creación de una aplicación en Blazor . Al final, tendremos un sitio listo para una pequeña pizzería, bastante al nivel de los sitios listos para algunas pizzerías. Por lo tanto, estarás orgulloso de;)

Esto será un poco fuera de lo común HelloWorld . Deliberadamente fui a algunas complicaciones que es mejor tomar de inmediato como reglas, en particular, esta es una arquitectura típica de tres capas: View-Domain-DataAccess .

Creo que es mejor seguirlo de inmediato que mostrar algo artificial, no relacionado con la vida. Como muestra la práctica, muchos desarrolladores se quedan atascados en el nivel HelloWorld y luego usan lo que vieron al diseñar aplicaciones grandes a priori (hola a mi ex-Most Green Bank of the Country y sus Service.cs con todo el código de la aplicación en un archivo, no estoy bromeando).

Te diré cómo mapear datos entre capas sin dolor y sin la necesidad de escribir muchas líneas de código. También implementaremos todo en Azure DevOps. Sí, ahora esta es una parte necesaria de cualquier proceso de desarrollo, todos volamos en las nubes hoy, algunos en las instalaciones , algunos en Azure o AWS .

Además, para que el primer artículo no sea una historia banal sobre cómo hacer clic en un botón en Visual Studio, y luego en otro, pensé que sería bueno organizar un pequeño desafío e intentar hacer algo en Linux por primera vez .

Espero que tenga un conocimiento mínimo de ASP.NET, C #. Aunque esto es HelloWorld, no hablaré sobre qué es Program.cs.

A continuación, discutimos qué más se necesita para programar en Linux .
Atención: en los siguientes párrafos, recibo mi impresión del trabajo real con Linux, que lo instaló con la mejor de las intenciones, si Linux le da sentimientos de entusiasmo y no puede vivir un solo día sin abrir la línea de comando, entonces puede arruinar su estado de ánimo, Continuando leyendo este artículo!

Distribución: Ubuntu


En verdad, no se sentirá cómodo programando en Linux, pero si desea concentrarse en los negocios, instale Ubuntu 19.10 . Logré ponerlo la segunda vez, es bueno que al menos la segunda vez. Y todos los equipos completaron la primera vez, casi todos. Recomiendo encarecidamente que no instale ninguna otra distribución, pasé todo el día configurando el último OpenSuse y luego lo demolí.

¿Por qué necesitas desarrollar bajo Linux ? Bueno, al menos porque .Net Core lo admite y tal vez su empleador decida ahorrar dinero y ejecutar todo en Linux en el producto. Y en mi opinión, la escritura es mejor bajo el sistema operativo en el que su aplicación realmente se ejecutará.

Ganador IDE: Jinete


Como dije, todavía no es posible escribir cómodamente en Linux ; para todos los males, elija el más pequeño, Rider.

Además de esto, también hay dos IDE más populares , como los editores de texto MonoDevelop y Visual Studio Code . Te contaré las desventajas de cada solución con más detalle.

Monodesarrollo


El más lindo de los tres editores. Fuentes legibles (las fuentes de baja calidad son lo primero que llamará su atención cuando se mude a Linux). Pero desafortunadamente detrás del hermoso shell hay un vacío, a pesar de los .Net Core 2.1 y 3.1 instalados , MonoDevelop persistentemente creó ConsoleApplication para mí con el objetivo .Net Core 1.1. Blazor no logró crear el proyecto, ni lanzar el creado manualmente.

Código visual de estudio


Estrictamente hablando, este no es un IDE , es un editor de texto con resaltado de sintaxis y capacidad de construcción. De las ventajas del tercer o cuarto intento, VS Code lanzó milagrosamente el proyecto WebAssembly que creé cuando MonoDevelop y Rider se negaron a hacer esto. Esta es una ventaja. Enumero aún más las desventajas: una fuente predeterminada pequeña e ilegible, creo que después de unos meses de trabajo regular, sus ojos simplemente se volverán locos.

La siguiente desventaja se deriva del hecho de que este es un editor de texto, ¿una acción tan simple como renombrar, mover proyectos? Todo lo que Visual Studio hace automáticamente, y lo damos por sentado, se hace manualmente aquí.

Jinete


Aquí todo es mucho mejor que los camaradas anteriores, Rider incluso recogió la plantilla que instalé para Blazor WebAssembly . E incluso creó una aplicación, pero por alguna razón este IDE se negó a lanzarla. En aras de la equidad, el servidor Blazor se ensambló y comenzó sin ningún problema. Rider

también le permite agregar un repositorio al crear un proyecto git. Pero al mismo tiempo .gitignore de alguna manera resultó estar vacío. Es decir, nuevamente, se requiere intervención manual, y Rider, por si acaso, te recuerdo, compite con VS y JetBrains

toma dinero para su producto. Bueno, y como de costumbre el problema, en general en Linux, en principio, estas son fuentes malas, son algunas muy delgadas, poco legibles. Los elementos también son todos pequeños, todavía necesitan ser apuntados. Además, varias veces, en dos días de trabajo, Rider colgó el sistema al cargar una solución simple. La computadora tuvo que reiniciarse con un reinicio, lo que por supuesto no es bueno (actualización: cuando se escribió este artículo, esto ya había sucedido cinco veces).

Ganador en la nominación Mejor IDE de C # para Linux :
Rider: a pesar de todas las deficiencias, me las arreglé para asegurarme de que este IDE ensamblara y lanzara el proyecto de manera consistente, nuevamente, por alguna razón, el navegador no se inició de manera predeterminada, esto debe hacerse manualmente.

A continuación, en la captura de pantalla, Rider (preste atención a las fuentes) y un intento de ejecutar el proyecto Blazor WebAssembly , creado por él mismo, con MonoDevelop en una situación similar.



Si todo es tan malo, ¿por qué usar Linux ?


Permíteme recordarte que este es un proyecto de capacitación, el objetivo era mostrar que aún puedes trabajar en Linux.

Además, la imperfección de las herramientas de desarrollo para Linux nos empuja a muchas acciones manuales que nos permitirán aprender un poco más sobre cómo funciona .Net bajo el capó y comprender cuánto trabajo hace Visual Studio para nosotros.

¿Qué queremos conseguir?


Al final, obtenemos una buena aplicación, como en el ejemplo a continuación:



Y ahora para el caso. Comencemos instalando .Net Core 3.1

Instalar .Net Core 3.1


.Net Core 3.1.1 SDK es la última versión disponible del SDK , está disponible en el repositorio de Ubuntu . Blazor cambia muy rápidamente, por lo tanto, para trabajar con Blazor WebAssembly, use 3.1.1, la última versión estable.

Al principio necesitamos registrar la clave de Microsoft y su repositorio, esto se hace con los siguientes comandos en la aplicación Terminal (haga clic en el botón Win e ingrese Term , debería aparecer en la lista de los 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

Ahora vaya directamente a la instalación de .Net Core SDK:

  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

Instalar la plantilla Blazor WebAssembly


Una vez finalizada la instalación de .Net Core , ahora debe instalar la plantilla de ensamblaje web de Blazor , que le recordaré mientras está en la etapa de vista previa, desde la cual se lanzará inmediatamente en mayo. Justo un día antes de comenzar a escribir el artículo, el 28 de enero se lanzó la versión actualizada 3.2.0-preview1.20073.1 (h)

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

Instalación de Git


Si aún no has instalado Git , entonces es hora de hacerlo. Estrictamente hablando, el primer comando no es necesario en absoluto, Ubuntu le pedirá que ingrese una contraseña, si se requieren privilegios para ejecutar el comando, lo anticiparemos =):

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

Eso no es todo, Blazor usa Mono cuando se ejecuta en el navegador , lo que significa que también necesitamos instalarlo.

Instalación mono


Primero, agregue los repositorios Mono al sistema:

  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

Ahora instale directamente Mono :

sudo apt install mono-complete

Este es un proceso rápido que tardó unos 10 minutos en mi computadora portátil con un procesador Core-i5 6200U, porque la compilación de la fuente se realiza directamente en su computadora.

¡Felicidades! Hemos instalado todo lo que necesita para desarrollar proyectos de Blazor WebAssembly.
Ahora puede ir directamente al proyecto en sí.

Pero antes de eso, tome un descanso de ingresar comandos y actualice en la memoria lo que es Blazor WebAssembly.

Blazor WebAssembly y con qué se come


Blazor es un marco web diseñado para ejecutarse en el lado del cliente en el navegador a través de la tecnología WebAssembly (usando .Net runtime , o más bien implementaciones Mono , que recientemente, gracias a la apertura de las fuentes .Net, casi no es diferente de la plataforma original), o en el lado del servidor con hosting en la aplicación Asp.Net Core e intercambio de datos a través de la tecnología SignalR (a través de la creación de conexiones de circuitos ).

Como puede ver en la descripción anterior, Blazor! = .Net WebAssembly implementación.
Si saca WebAssembly de este paquete , puede desarrollar una aplicación Blazor Server y funcionará incluso en IE 11quien nunca escuchó nada sobre la tecnología moderna y gracias a Dios que nunca volverá a escuchar.

Dado que estamos haciendo una aplicación basada en el enfoque Blazor WebAssembly . Luego lo consideraremos un poco más.

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

    Blazor , .

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

    Blazor , , , .
  2. Quizás la principal desventaja de este enfoque es la depuración complicada, no puede establecer puntos de interrupción, simplemente no caerá en ellos, aunque creo que esto es temporal, porque fue posible conectarse a IE y depurar el código JS anteriormente en el estudio .

    Bueno, tal vez el segundo inconveniente obvio es la necesidad de descargar todas las fuentes, una vez más, creo que todavía hay muchas oportunidades para la optimización.
  3. En realidad, después de la descarga y todos los procesos preparatorios, nuestra aplicación se ejecuta en la secuencia de interfaz de usuario del navegador y comienza su ejecución. Puede llamar a cualquier código JS desde C # y viceversa.

No ha habido fotos durante mucho tiempo, así que aquí hay una a continuación :)



Utilidad Dotnet


Además, utilizaremos activamente la utilidad del .Net Core SDK - dotnet.

Le permite hacer muchas cosas útiles, solo nos interesan algunas:

dotnet build 

El comando anterior recopila la solución, si comienza desde la carpeta con la solución, no se requieren argumentos.

dotnet new blazorwasm -ho -o BlazingPizza

Le permite crear un nuevo proyecto basado en la plantilla que viene después de la palabra nuevo, en nuestro caso es blazorwasm , aquí, por ejemplo, puede especificar classlib o consola .

A continuación se muestran los parámetros específicos de la plantilla, en este caso -ho , este parámetro indica que nuestra solicitud será alojado en el lado del servidor en el ASP.NET Core aplicación, también .Net creará controladores para nosotros, que podemos utilizar, en particular, para crear API web y acceda no solo desde la aplicación Blazor, sino también desde otros clientes.

La última opción -o indica la carpeta en la que se colocará la solución creada, de manera predeterminada, este es el directorio actual.

dotnet run 

Otro equipo que resulta útil, como su nombre lo indica, lanza nuestra aplicación.

Creación de proyectos


Y entonces ejecutaremos el equipo familiar para generar nuestra solución. Para esto, seleccione un lugar que conozca, por ejemplo, la carpeta RiderProjects que creó el IDE de Rider y que se encuentra en la ruta / home / {userName}:

dotnet new blazorwasm -ho -o BlazingPizza


Después de crear, crearemos el proyecto y finalmente lo ejecutaremos para disfrutar de qué tipo de resultado (el primer comando se ejecuta en el nivel de archivo BlazingPizza.sln):

dotnet build


Todo debería haber pasado sin problemas, vaya a la carpeta Servidor y ejecute:

dotnet run


Y finalmente, vemos el resultado apreciado:



Genial, todo funciona. Ahora, no nos olvidemos de la apariencia del sitio durante mucho tiempo y pasemos a sus contenidos.

El resultado del primer comando (dotnet new) fue una estructura de carpetas de este tipo:



en mi opinión, este no es un buen esquema, es mejor si las carpetas tienen un prefijo con el nombre de la solución, es más familiar (esto es lo que hace VisaulStudio al crear nuevos proyectos) y dejar en claro que esto no es algún tipo de ext. carpeta de servicio Con el tiempo, el proyecto puede crecer en muchas carpetas que no contienen código C # , y si va al Explorador , será difícil navegar donde, además, puede haber algún desplieguescripts basados ​​en el hecho de que en cada carpeta cuyo nombre comienza con el nombre de la solución, se encuentra el proyecto, esto es normal, porque este es el comportamiento a largo plazo de Visual Studio y puede confiar en él.

Por lo tanto, cambiamos el nombre de los proyectos y carpetas existentes que los contienen (hasta ahora no sabemos nada sobre el IDE , estamos en Linux , y por primera vez no ayudará, porque las carpetas y los proyectos se nombran de manera diferente):

Cliente => BlazingPizza.Client
Servidor => BlazingPizza.Server
Shared => BlazingPizza.Shared Los

cambios correspondientes deben mostrarse en el archivo de solución BlazingPizza.sln . Donde se indica la ruta al proyecto "[Servidor] \ ~" y a continuación reemplazaremos en consecuencia con"BlazingPizza. [Servidor] \ ~" como en la captura de pantalla a continuación:



Hagamos cambios similares en el archivo BlazingPizza.Server.csproj:



Y finalmente, BlazingPizza.Client.csproj debería verse como la captura de pantalla a continuación:



Con los cambios por ahora, tenemos suficiente se ha acumulado suficiente como para que sea una pena perder, por lo que conectaremos un sistema de control de versiones a nuestra solución. Para hacer esto, finalmente abra nuestro IDE Rider y nuestras soluciones, aquí todo es igual que en Visual Studio, puede abrir seleccionando un archivo de solución.

Una vez que todo esté cargado, vaya al menú VCS => Habilitar integración de control de versiones . Y aquí conectamos Git. Rider agregará archivos de servicio a la carpeta con la solución y resaltará todos los archivos en rojo, lo que significa que estos archivos no están arreglados en el sistema de control de versiones.
La primera vez que Rider ofrecerá confirmar todo lo que está en el proyecto, incluidos los contenidos de las carpetas bin y obj , ciertamente no necesitamos esto, todo porque el archivo .gitignore que se agregó por defecto está vacío. Muévalo al nivel raíz uno con el archivo BlazingPizza.sln y reemplace su contenido con el contenido debajo del kata.

El contenido del archivo .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


Después de eso, el número de archivos no comprometidos tendrá que disminuir drásticamente a 31.

Cree nuestro primer compromiso en la pestaña Repositorio:



ingrese el compromiso inicial en la descripción del compromiso e incluya todos los archivos en el compromiso haciendo clic en "Archivos no versionados" => "Agregar a VCS" :



C la infraestructura está más o menos lista, hablemos un poco sobre el contenido de la solución.

Contenido de la solución


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.

Cambie el nombre del proyecto BlazingPizza.Shared ahora mismo a BlazingPizza.DomainModels . Aquí hay que decir que Rider, a pesar de la marca experimental, hizo un excelente trabajo. Ejecute el proyecto y asegúrese de que todo esté funcionando y que nada esté roto.



Sería bueno crear un compromiso con los cambios, aunque solo sea para ver cuánto Rider hizo por nosotros, permítame recordarle que si fue Visual Studio Code , tendría que hacer todo esto con lápices. usted mismo, mire los archivos diff haciendo clic en ellos.



Agregar nuevos proyectos


Agregue algunos proyectos más, comience con BlazingPizza.ViewModels . Mostrará los modelos de pantalla en el cliente. Para agregar, haga clic derecho en la solución y seleccione Agregar => Nuevo proyecto (el tipo de proyecto en este y en el siguiente en esta parte de la Biblioteca de clases )


BlazingPizza.DataAccess.ModelsModelos utilizados en la capa para acceder a los datos de la base de datos.
BlazingPizza.DataAccess.InfrastructureTodo lo que es responsable de interactuar con la base de datos.
BlazingPizza.Services.InterfacesLas interfaces para servicios están separadas de las implementaciones, de modo que si usa otras implementaciones que no sean las predeterminadas, no es necesario arrastrarlas junto con usted.
BlazingPizza.ServicesImplementación de servicios, por ejemplo, PizzaService , que agregará pizza a la base de datos mientras realiza algún tipo de comprobaciones relacionadas con la lógica empresarial.

Si algo salió mal, o simplemente no quiere perder el tiempo configurando y comenzando desde la segunda lección, la fuente está aquí .

Ah, sí, casi lo olvido :) Enlace al proyecto original (Licencia MIT) .

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


All Articles