Zewnętrzna paczka do obsługi autentykacji w aplikacjach Asp.Net Core.

Siemanko.

Coraz częściej znajomi pytają się mnie czy nie zrobiłbym im stronki. Oczywiście bez żadnych fajerwerków, ale chcieli by mieć możliwość edycji treści, a więc oprócz statycznej stronki trzeba zrobić jakiś CMS’ik. Jak już ktoś ma edytowac content to dobrze by było gdyby to była osoba, która ma do tego prawo, a nie każdy kto wejdzie na odpowiedni url 😉 Dlatego potrzebna jest autentykacja. Oczywiście jest gotowe rozwiązanie o nazwie Microsoft.Identity, ale wymaga ono bazy danych i ogólnie jest to wyciąganie armaty na komara. Z kolei za każdym razem robić obsługę autentykacji dla każdej aplikacji też by mi się nie chciało (lenistwo) dlatego pomyślałem, że napiszę coś zewnętrznego w class library, spakuję w paczke i wrzucę do nugeta. W taki sposób, w kilka kliknięć i kilka linijek kodu będe miał rozwiązaną obsługę autentykacji (oczywiście na prostym poziomie).

Funkcjonalności

Plan jest taki aby konfiguracja wymagała dodania jednej linijki kodu w klasie Startup.cs oraz jednej linijki przy logowaniu. Będzię się to wiązało z doklejeniem ciasteczka zawierającego token JWT oraz jego validacją w middleware tuż przed wejściem do MVC. W ten sposób po sprawdzeniu property User.Identity.IsAuthenticated bedę wiedział czy user jest zalogowany czy nie. Planuje także dorobic obsługę delegata, który będzie uzupełniał User.Identity o odpowiednie dla danej aplikacji dane z tokena (nazwa usera, uprawnienia, itp.). To jak go będę logował to juz zupełnie inna sprawa (czy bedę sprawdzał w bazie, w pliku, w innej aplikacji – to już inna bajka). Biblioteczka będzie jedynie validowała wchodzące requesty oraz tworzyła i doklejała ciasteczko do response.

Kodzik

Kodzik wrzuciłem na github’a.

Pjona!

 

[Subiektywnie] Dobra pozycja do zrozumienia czym jest DDD i jakie niesie ze sobą korzyści.

Simanko.

Od długiego czasu słyszy się o DDD. Sam słuchałem w 2015r. jednej prelekcji na żywo natomiast drugą oglądałem na prulal sight (Dino Esposito). Godzinna czy dwu godzinna pogadanka w moim przypadku zbyt wiele mi nie uświadomiła prócz tego, że DDD to nie jedynie technologie wykorzystywane do tworzeniu kodu, a filozofia, podejście do całego procesu wytwarzania oprogramowania, które nie dotyczy tylko zespołu programistów, a całego przedsiębiorstwa. Jeśli masz podobnie, a jednak ciekawi Cię o co kaman w tym całym Domain Driven Design to polecam Ci książkę DDD autorstwa Vaughn Vernon’a. Sam kupiłem ją przypadkiem, ponieważ dowiedziałem się pewnej soboty, że akurat tego dnia była przeceniona o 50% w helionie więc grzechem było nie skorzystać z takiej okazji :). Czytam ją w wolnym czasie i w tej chwili mam za soba ok 1/3 książki, a już dostrzegłem jak różne jest DDD od podejścia np. u mnie w firmie (w której pracuję) i jak bardzo wiele popełniliśmy (nadal popełniamy) błędów.

Na tę chwilę jestem najbardziej zajarany architekturą sterowaną zdarzeniami i magazynowaniem zdarzeń (event source’ingiem) dlatego możecie się niedługo spodziewać nowych kodów na moim github’ie z jakimiś małymi wymyślonymi aplikacjami, w których będę starał się implementować wzorce wykorzystywane w DDD.

Pjona!

Prosty generator memów.

Siemanko.

Jak zapowiadałem w poprzednim poście będę strał się wrzucać na github’a każdy kodzik, który napiszę, a tutaj będę opisywał powód jego powstania.

Spory portal na horyzoncie

Dostałem nie dawno  do wyceny draft portalu internetowego, który ma zamiar powstać. Jest w nim na prawdę dużo funkcjonalności, które trzeba spiąć w portal rankingowy. Na długiej liście funkcjonalności jest sporo takich, których nigdy nie robiłem więc ciężko mi się określić ile taki task może zająć. Takim taskiem jest m.in. generator memów. Korzystając z wolnego popołudnia spróbowałem coś zrobić i jak się okazało nie jest to takie trudne 😉 Oczywiście w najprostszej formie, ale dzięki temu wiem, że nie będę ślęczał nad tym wiele dni, a raczej zamknie się to w kilkunastu godzinach.

Jak?

Z użyciem elementu canvas i javascriptu. Nie ma co tu za dużo gadać. Wszystko jest na githubie.

gif-generator

Pjona!

Workaround umożliwiający czytanie widoków SQL w Entity Framework Core 1.1.0

Siemanko.

Od dawna nic nie piszę, ale postanowiłem to zmienić i co więcej, oprócz pisania planuje troszkę publicznie pokodować i pushować na github’a.

Często rozmyślam nad problemami pojawiającymi się podczas codziennej pracy z różnymi technologiami i równie często tworze w domu nowe solucje w Visual Studio tylko po to aby sprawdzić pomysły na rozwiązania wcześniej wspomnianych problemów. Ostatnio zadałem sobie pytanie czemu by tego nie wrzucać do sieci i w dodatku mieć jakiś temat na post na tym moim nieszczęsnym blogu? 😉 Dlatego od teraz każdy poryty kod bedzie lądował na githubie, a tu z kolei kilka zdań na temat przyczyn jego powstania 🙂

EF Core nie wspiera widoków SQL

Ostatnio w robocie piszę funkcjonalności związane z raportowaniem ilościowym danych wg wielu kryteriów. W projekcie używamy tylko i wyłącznie Microsoft’owego ORMa w wersji Core (gdyż aplikacja jest w Asp.Net Core). Przy tego typo raportach, które mam okazję implementować EF wypada bardzo słabo czasowo ponieważ where’owanie czy group’owanie po kolumnie w czwartej z kolei join’owanej tabeli powoduje, że ef musi wykonać całe query jeszcze przed uwzględnieniem where’a aby mieć zmapowane dane z tej czwartej join’owanej tabelki żeby w końcy wykonać na tych danych where’a. 🙂 Wiem, nieźle zakręciłem, ale chodzi finalnie o to że mimo iż w wyniku dostaniesz 10 rekordów to EF może wcześniej wykonać query na 10000 tys. rekordów żeby mieć dostęp do danych z którejś z kolei zjoinowanej tabelki, które zostały uwzględnione w klauzuli where :). W celu poprawy wydajności pomyślałem żeby stworzyć widok SQL, w którym będę miał wszystkie potrzebne kolumny. Niestety EF Core nie wspiera (jeszcze) widoków w przeciwieństwie do EF 6.

Workaround

Wymyśliłem sobie kontekst sklepu. W sklepie jest klilka produktów, które sa pogrupowane w kategorich. Produkt może byc w wielu kategoriach i kategoria może mieć wiele produktów więc mamy tabelkę łączącą relacje wiele do wielu. Oprócz tego produkty sa powiązane relacją jeden do wielu z tabelka zdjęć. Zdjęcie może być tylko dla jednego produktu, a produkt może mieć wiele zdjęć. Chcę pobrać listę kategorii z ich podstawowymi informacjami wraz z jednym losowym produktem i jego zdjęciem oznaczonym jako IsMinPhoto (czyli miniaturka).

Ef Core umożliwia wykonania selecta z czystego SQL poprzez metodkę FromSql(). Metodka ta może zostać wywołana na propercie DbSet<> obiektu DbContext. Utworzyłem sobie zatem model zawierający kolumny, które będą w widoku. Po utworzeniu bazy zostanie utworzona taka tabela jednakże będzie ona zawsze pusta. Tabela wymaga posiadania klucza Id na podstawie, którego EF mapuje rekordy z bazy danych na obiekty jednakże widok nie posiada swojego Id, gdyż jest to tylko zestaw kolumn z innych tabel. Jako klucz dla modelu odwzorującego widok dodałem pole typu string. Bardzo ważne jest aby odpowiednik tego pola znalazł sie także w widoku z tabelki, której rekordy się nie powtarzają w żadnej relacji (w moim przypadku tabelka Photo). Następnie utworzyłem widok SQL w SQL Managment Studio z użyciem designera.

model

Model EF

Bez tytułu.jpg

Widok SQL w SQL Mangment Studio

Czytanie z widoku

queryview

Podsumowanie

Zrobiłem porównanie czasowe z normalnym zapytaniem zrobionym przez Linq na ORMie i przy łącznie raptem kilkunastu rekordach we wszystkich tabelach wyciąganie danych z widoku jest 3krotnie szybsze i w Sql Profilerze widać tylko jedno zapytanie natomiast gdy robił to ORM zapytań w tym przypadku było 3.

Kodzik z testami do uruchomienia znajduje się na githubie.

Pjona!