Jak efektywnie łączyć Blazor, Razor Pages i MVC w ASP.NET Core 9?

W przypadku prostych komponentów, podejście polegające na używaniu kodu HTML i C# w tym samym pliku może być wystarczające. Niemniej jednak, zgodnie z dobrą praktyką, warto oddzielić zasady biznesowe od interfejsu użytkownika. Blazor pozwala na tworzenie pliku zawierającego kod C# komponentu. W przykładzie kodu powyżej, utworzono dwa pliki: Counter.razor i Counter.razor.cs. Wszystkie operacje w C# zostały przeniesione do nowego pliku, tworząc następującą klasę:

csharp
Copy code
namespace MyFirstBlazorApp.Pages;

public partial class CounterPartialClass {
    private int currentCount = 0;
    private void IncrementCount() {
        currentCount++;
    }
}

Blazor jest wyjątkowo elastyczny i oferuje szeroki wachlarz możliwości tworzenia zaawansowanych aplikacji internetowych, zintegrowanych z HTML, CSS i JavaScript oraz wykorzystujących najnowocześniejsze technologie. Choć stworzenie książki tylko na temat Blazora wymagałoby ogromnego wysiłku, w tej publikacji skupimy się na podejściu bazującym na Razor Pages i MVC. ASP.NET Core 9 jest niezwykle elastyczny, oferując różnorodne podejścia do tworzenia interfejsów użytkownika, bazując na różnych frameworkach. Jeśli jednak masz doświadczenie w pracy z Angular, React czy Vue.js, możesz wykorzystać moc platformy .NET.

ASP.NET Core 9 i frameworki JavaScript

Jak widzieliśmy podczas omawiania innych tematów w tym rozdziale, ASP.NET Core 9 oferuje kilka podejść do budowania interfejsu użytkownika i interakcji z kodem C#. Istnieje wiele korzyści z tego rozwiązania, w tym używanie wspólnego modelu rozwoju, wykorzystanie składni Razor oraz wszystkich korzyści płynących z platformy .NET. Jednak jeśli jesteś przyzwyczajony do używania frameworku do tworzenia aplikacji jednostronicowych (SPA), takich jak Angular, Vue.js lub React, platforma .NET posiada dostępne szablony do tego celu:

Szablon ASP.NET Core 9 dla React tworzy dwa projekty: jeden dla frontend, drugi dla backendu aplikacji. W przypadku aplikacji SPA, UI jest rozwijane niezależnie od backendu, który zazwyczaj jest zewnętrzną usługą lub aplikacją. Korzystając z modelu oferowanego przez ASP.NET Core, zachowana jest wyraźna separacja między interfejsem użytkownika a backendem. Projekt jest już skonfigurowany do integracji z API webowym stworzonym w .NET.

Jednym z głównych atutów tego rozwiązania jest wygoda publikowania projektu UI i backendu w jednej, prostszej jednostce, co upraszcza proces publikacji aplikacji.

Frameworki takie jak Angular, Vue.js czy React są opcjonalnymi rozwiązaniami. Nawet jeśli projekt UI zostanie stworzony niezależnie, możemy skorzystać z ASP.NET Core do tworzenia web API, które będzie obsługiwało UI. O tym, jak stworzyć API, porozmawiamy w trzecim rozdziale. Platforma oferuje różnorodne podejścia do tworzenia wysokiej jakości aplikacji webowych, a każdy framework UI w ASP.NET Core posiada swoje zalety, które można łączyć, by stworzyć jeszcze bardziej zaawansowane rozwiązania.

Praca z rozwiązaniami hybrydowymi

Jedną z największych zalet pracy z tak potężną platformą jak ASP.NET Core jest możliwość integracji różnych technologii. W związku z tym, można połączyć wszystkie atuty Razor Pages, MVC i Blazor w jednym projekcie. W przypadku integracji z Blazorem, zyskujemy możliwość używania komponentów .razor, co zapewnia dużą reużywalność kodu.

Integracja Blazora w projekcie Razor Pages lub MVC wymaga wykonania kilku kroków:

1. W katalogu głównym projektu dodaj plik o nazwie _Imports.razor. Ten plik będzie odpowiedzialny za importowanie niezbędnych przestrzeni nazw do projektu:

razor
Copy code
@using System.Net.Http

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.JSInterop
@using {CHANGE_FOR_THE_NAMESPACE_OF_YOUR_PROJECT}

2. Następnie musisz zmienić plik _Layout.cshtml znajdujący się w katalogu Pages/Shared (w przypadku Razor Pages) lub Views/Shared (w przypadku MVC). Należy dodać odpowiedni kod w sekcji head, aby zdefiniować ścieżkę bazową aplikacji i umożliwić renderowanie komponentów Razor w elemencie head HTML.

3. Kolejnym krokiem jest dodanie odpowiedniego skryptu przed sekcją @await RenderSection(...). Nie martw się o ścieżkę skryptu, ponieważ zostanie ona automatycznie wygenerowana przez framework.

4. Otwórz plik Program.cs i zarejestruj usługi Blazora, aby były dostępne podczas działania aplikacji. Dodaj następujący kod:

csharp
Copy code
builder.Services.AddServerSideBlazor();

5. Musisz także dodać kontrolę mapowania tras Blazora. Dodaj poniższą linię poniżej wywołania MapRazorPages() (w przypadku Razor Pages) lub MapControllerRoute() (w przypadku MVC):

csharp
Copy code
app.MapBlazorHub();

Po zintegrowaniu projektu z Blazorem, możesz stworzyć komponent zgodnie z poniższymi krokami:

1. Utwórz plik o nazwie technology.razor w katalogu Pages/Shared (Razor Pages) lub Views/Shared (MVC) i dodaj poniższy kod:

razor
Copy code
<button @onclick="LoadTechnologies">Load Technologies</button>

@if (technologies != null) {
    @foreach(var tech in technologies) {
        <p>@tech</p>
    }
}
@code {
    private int currentCount = 0;
    private string[]? technologies;
    private void LoadTechnologies() {
        technologies = new[] { "Razor Pages", "MVC", "Blazor"};
    }
}

2. Aby użyć tego komponentu, wystarczy dodać poniższy kod w dowolnej stronie Razor lub widoku MVC.

Podczas uruchamiania aplikacji, wyświetli się komponent, który umożliwia ładowanie listy technologii. Taki komponent jest wielokrotnego użytku i może być dodany do dowolnej strony lub widoku, zwiększając elastyczność i moc rozwoju interfejsu użytkownika.

Łączenie różnych frameworków UI w ASP.NET Core umożliwia tworzenie aplikacji internetowych z wykorzystaniem najlepszych cech każdego z podejść, co przyczynia się do powstania bardziej zaawansowanych i elastycznych rozwiązań.

Jak wybrać odpowiedni model przechowywania danych: NoSQL czy SQL?

W dzisiejszych czasach technologia chmurowa, w tym Platforma jako Usługa (PaaS), zyskuje na popularności, umożliwiając firmom abstrahowanie wielu procesów związanych z przechowywaniem danych. Jednak korzystanie z tych rozwiązań wiąże się z pewnymi kosztami. Wraz z rozwojem technologii pojawiły się nowe modele przechowywania danych, które oferują szerokie możliwości zarówno dla aplikacji, jak i dla przedsiębiorstw. Jednym z pojęć, które przez wiele lat było źródłem nieporozumień w środowisku technicznym, jest termin NoSQL, oznaczający bazy danych nienośnikowe lub inaczej – "nie tylko SQL".

Model ten jest alternatywą dla tradycyjnego modelu relacyjnego. Bazy danych NoSQL charakteryzują się elastyczną strukturą danych, która nie wymaga ściśle zdefiniowanych schematów, co sprawia, że model ten jest bardziej otwarty na różne formaty przechowywania informacji. Przez wiele lat NoSQL był postrzegany jako nowoczesny sposób przechowywania danych w systemach zarządzania bazami danych (DBMS), co skłoniło wiele firm do migracji na ten model, nie do końca rozumiejąc podstawy i próbując stosować podejście relacyjne do struktur NoSQL.

Podejście NoSQL zmienia sposób pracy z danymi, oferując elastyczność i prostotę, jednak nie zawsze pozwala na pełne wykorzystanie zalet tradycyjnych baz danych. Często towarzyszy temu zmiana perspektywy programistów, inżynierów i firm, które zaczynają koncentrować się na biznesowych potrzebach aplikacji, zamiast martwić się o sposób przechowywania danych. Zasadniczo, bazy danych NoSQL oferują kilka modeli przechowywania danych, które różnią się od tradycyjnych baz danych relacyjnych. Do najpopularniejszych typów należą:

• Magazyny klucz-wartość (np. Redis, Memcached)

• Bazy danych dokumentowe (np. MongoDB, Couchbase)

• Bazy danych kolumnowe (np. Cassandra, HBase)

• Bazy danych grafowe (np. Neo4j, OrientDB)

Każdy z tych typów ma inne podejście do manipulacji danymi i zapytań, a także wymaga różnego podejścia w zależności od specyfiki projektu. Warto zauważyć, że zapytania w bazach NoSQL mogą nie być tak standardowe jak w SQL, a sposób pracy z danymi zależy od typu bazy.

Bazy NoSQL często priorytetowo traktują skalowalność, wydajność dla określonych wzorców zapytań oraz elastyczność w obsłudze zmieniających się struktur danych. Kiedy więc należy używać jednego podejścia zamiast drugiego? Aby odpowiedzieć na to pytanie, należy porównać cechy obu typów baz danych.

Tabela porównawcza między bazami danych relacyjnymi a NoSQL obrazuje główne różnice:

Obydwa podejścia — zarówno bazy RDBMS, jak i NoSQL — mają swoje miejsce w ekosystemie nowoczesnych aplikacji. Relacyjne bazy danych świetnie sprawdzają się w przypadkach, gdy kluczowe jest zachowanie integralności danych, a struktura bazy jest przewidywalna. Natomiast NoSQL zyskuje przewagę w aplikacjach, które wymagają elastyczności, masowej skalowalności oraz dużej wydajności przy specyficznych wzorcach zapytań.

ASP.NET Core 9 umożliwia pracę z różnymi typami modeli danych, oferując elastyczność i dynamiczność w projektowaniu aplikacji. Dzięki temu deweloperzy mogą wybierać, który model przechowywania danych najlepiej pasuje do ich potrzeb.

Chociaż NoSQL oferuje wiele korzyści, szczególnie w kontekście dużych, rozproszonych aplikacji o dużych wymaganiach dotyczących skalowalności, równie ważnym aspektem jest zrozumienie roli ORM i Micro ORM w zarządzaniu danymi. ORM (Object-Relational Mapping) to technika, która stanowi pomost między obiektowym programowaniem a światem baz danych. ORM umożliwia mapowanie obiektów w aplikacji na tabele w bazie danych, eliminując potrzebę ręcznego pisania zapytań SQL dla każdej operacji na danych. Entity

Jak działa HttpContext.User w ASP.NET Core i jak to wpływa na bezpieczeństwo aplikacji?

W ASP.NET Core obiekt HttpContext.User stanowi kluczowy element obsługi kontekstu bezpieczeństwa użytkownika w trakcie przetwarzania żądania HTTP. Jest to instancja klasy ClaimsPrincipal, która zawiera tożsamość użytkownika w postaci tzw. "claims" — czyli zestawu twierdzeń opisujących atrybuty użytkownika, takie jak jego nazwa, adres e-mail czy role (np. administrator, członek). Podczas procesu uwierzytelniania middleware odpowiedzialny za autoryzację odczytuje z żądania tokeny lub ciasteczka uwierzytelniające, weryfikuje ich ważność, a następnie tworzy obiekt ClaimsPrincipal. Ten może zawierać kilka tożsamości ClaimsIdentity, z których każda ma zestaw "claims", pozwalających jednoznacznie określić i zweryfikować uprawnienia użytkownika.

Takie podejście umożliwia aplikacjom ASP.NET Core sprawdzanie, czy dany użytkownik ma uprawnienia do wykonania określonych operacji lub dostępu do zasobów. Przykładowo, w kodzie akcji kontrolera możemy odwołać się do HttpContext.User, by zweryfikować, czy użytkownik jest uwierzytelniony, a następnie na podstawie jego tożsamości (np. nazwy użytkownika) wykonać odpowiednie działania. To wbudowane mechanizmy, które realizują autoryzację na poziomie całej aplikacji.

Autoryzacja opiera się także na middleware, które analizuje, czy dana trasa wymaga uwierzytelnienia i autoryzacji. Jeśli tak, to weryfikuje poprawność przesłanego tokena, pozwalając na wykonanie żądania tylko wtedy, gdy token jest ważny. Middleware to fragment oprogramowania w potoku przetwarzania żądania, który może modyfikować lub rozszerzać jego zachowanie. W ASP.NET Core middleware takie dodajemy zwykle w pliku Program.cs, wywołując metody jak app.UseAuthentication() oraz app.UseAuthorization().

Charakterystyczną cechą nowoczesnych aplikacji, zwłaszcza cloud-native, jest bezstanowość (stateless). Oznacza to, że serwer nie przechowuje informacji o stanie klienta pomiędzy kolejnymi żądaniami. Dzięki temu aplikacja jest łatwa do skalowania i odporna na przeciążenia. Każde żądanie zawiera niezbędne informacje, takie jak token uwierzytelniający, co pozwala serwerowi na samodzielną weryfikację tożsamości użytkownika bez konieczności zarządzania sesją po stronie serwera. To eliminuje problemy z synchronizacją sesji czy blokadą zasobów w rozproszonych środowiskach.

Z tego względu najlepszą praktyką jest oddzielanie konfiguracji poufnych od kodu aplikacji oraz korzystanie z bezpiecznych mechanizmów zarządzania sekretami, dostępnych w ASP.NET Core 9. Ponadto, kod można zabezpieczać technikami obfuskacji (zaciemniania kodu), które utrudniają inżynierię wsteczną i analizę logiki przez osoby trzecie. Proces ten obejmuje m.in. zmianę nazw zmiennych na nieczytelne symbole, szyfrowanie ciągów znaków czy modyfikację przepływu sterowania.

Warto zdawać sobie sprawę, że nawet jeśli aplikacja znajduje się w prywatnym repozytorium, dostęp do niej mogą mieć różni pracownicy czy partnerzy biznesowi, dlatego należy przywiązywać wagę do tego, które informacje są tam przechowywane. Odpowiednia separacja i zar