nauka

Logowanie przy pomocy Facebook, Twitter czy Google – OWIN Katana na ASP MVC 5

~ Jarosław Stadnicki ~ 2 Comments

Następny wpis, tym razem już na nowym systemie i nowej własnej domenie. Zobaczymy czy będzie tak jak z samochodami, gdzie wizyta na myjni daje dwa konie mechaniczne więcej. Ostatnio pisałem więcej filozoficznie, dzisiaj powrót do twardej rzeczywistości.

Obejrzałem nie dawno na pluralsight fajny i krótki kurs o OWIN i Katana i częścią wiedzy chce się z wami podzielić.
Kto z was zaczynał projekt ASP MVC z włączonymi indywidualnymi kontami użytkowników? Ja na pewno! Także ja, gdy patrzyłem co się dzieje w OWINIE (w części konfiguracyjnej) i AccoutController łapałem się za głowę i zastanawiałem się WTF? Oczywiście próbowałem zrozumieć o co tam chodzi i czemu to wszystko jest tak “fajnie” napisane, niestety nie starczyło mi na to nigdy cierpliwości. Koniec końców pogodziłem się z tym faktem i korzystałem z tego tak jak jest, działało a ja nie zadawałem pytań – sprzedawać!

Teraz to wszystko może się zmienić! (dramatyczna muzyka i suspens – teraz!)

Aby to wszystko zrozumieć, zacząć należałoby od stworzenia pustego projektu MVC5 (tak, wiem staroć) – żadnych dodatkowych referencji, nic! Jak się bawić to na trylion procent. Na koniec wpisu, znajdziecie link do całego projektu. Dodajemy samodzielnie referencje do OWINowych rzeczy, tak aby moje i wasze referencje w tej kwestii się zgadzały:

  • Microsoft.Owin
  • Microsoft.Owin.Host.SystemWeb
  • Microsoft.Owin.Security
  • Microsoft.Owin.Security.Cookies
  • Microsoft.Owin.Security.Facebook
  • Microsoft.Owin.Security.Google
  • Microsoft.Owin.Security.Twitter

Z racji tego że projekt będzie oparty o MVC, nie można zapomnieć o:

  • System.Web.Mvc
Kompletna lista referencji w projekcie
Kompletna lista referencji w projekcie

Gdy to mamy ogarnięte, warto dodać plik z punktem wejścia do aplikacji, wykorzystany zostanie także do konfiguracji facebooka, twittera czy G+ oraz ogólnej authentykacji, u mnie wygląda on tak:

Co tam ciekawego? Na początku (@14) informujemy aplikację, o chęci korzystania z autentykacji opartej o ciastka. Ciastko przenosząca tajne dane nazywamy ThisCanBeAnythingYouLike. Następnie (@20-@41) wpinamy kolejne warstwy umożliwiające użytkownikom logowanie się przy pomocy FB, Twittera czy G+. Należy podać sekretne kody jednoznacznie identyfikujące waszą aplikacje.

Uwaga (@32) tutaj null oznacza, że nie interesuje mnie walidacja certyfikatów Twittera, oznacza to nie mniej, nie więcej, że jeśli ktoś podszyje się do Twittera i sprzeda mi swój certyfikat, ja to łyknę jak młody pelikan. Taka zagrywka przejdzie na blogu. Na żywej produkcji, należy odnaleźć aktualnie używane certyfikaty Twittera i dodać jest do walidacji. Dodatkowo zwracam uwagę, że wszystkie formy authentykacji korzystają z tego samego ciastka, znowu na blogu nie robi mi to różnicy skąd i jak i czym logują się moi użytkownicy. Produkcja rządzić może się swoimi prawami.
“/Auth/Login” (@14) ta linijka mówi, gdzie należy się przekierować gdy użytkownik nie będzie zalogowany, a aplikacje będzie tego wymagać.
Dla przypomnienia odpowiednio atrybuty AllowAnonymousAttribute oraz AuthorizeAttribute.

Skoro już powiedziałem o przekierowaniu do “/Auth/Login” (Auth controller, Login action) zajrzyjmy co kryje się w tej klasie:

Wielkiej ilości kodu nie ma (gdzie jest AccountController?!). Zaczynając od metody [HttpGet]Login (@15) tworzymy prosty pusty model do logowania się użytkownika. Z OWINa wyciągamy informacje o zarejestrowanych providerach (dostarczycielach?) logowania i wpychamy do modułu, który potem renderujemy.

W parach pracuje się lepiej, dlatego istnieje także [HttpPost]Login (@29) który przyjmuje ten sam model(pamiętamy, że to tylko wpis na blogu i nie maiłczymy że model!=dto!=viewmodel). W klasie są informacje o nazwie i haśle, następuje skomplikowana weryfikacja i jeśli dane są poprawne tworzymy w locie użytkownika. Nadajemy mu także pewne cechy: nazwę oraz identyfikator. Tak zdefiniowanego użytkownika logujemy przy wykorzystaniu OWINa. I wracamy do domu, jeśli weryfikacja się nie powiedzie, dajemy kolejną szansę.

Dla znudzonych oferujemy opcję wylogowania (@47) jak zawsze wszystko kręci się wokół OWINa.

Wreszcie! WRESZCIE! Jak zobaczycie zaraz na przykładzie z razora, tutaj obsługujemy kliknięcie użytkownika, gdy wybierze ono (!on i !ona) opcję logowania się przy pomocy FB, Twitter czy G+. Jako parametr wejściowy przyjdzie nazwa providera. Następnie na OWINie i autentykacji wywołujemy metodę Challange z parametrem informującym, że chcemy wrócić do “/secret”. Kod tego kontrolera pokaże na końcu. Po wywołaniu zwracamy jeszcze odpowiedni kod HTTP aby wszystkim formalnościom stało się zadość. Status Unauthorized jest bardzo ważny i nie może zostać pominięty.

No dobrze, skoro tutaj tak mało kodu, to pewnie razor będzie przekombinowany, pomyślało teraz ono. Aby nie trzymać w niepewności:

Pierwsze linie wynikają z braku pełnej integracji z MVC, odpowiednich wpisów w web.config etc. Ignoruj. Linie (@15-@30) to forma gdzie można się zalogować jako aplikacyjny użytkownik. Linie (@32-@37) to pętla, która wyciąga z modelu (ono przypomina sobie teraz AuthController::Login) listę providerów, na jej podstawie tworzy proste linki z nazwą providera oraz odpowiednim id (“Facebook”, “Twitter”, “Google”), które zostanie przekazane do metody SocialLogin (AuthController::SocialLogin) i użyte to rozróżnienia providera.

Co teraz? Gdzie jest reszta, gdzie jest ACCOUNTCONTROLLER? Nie ma i nie potrzeba. Póki co, nie będę nigdzie zapisywać użytkowników. Demo pokazuje tylko jak zalogować się przy pomocy providerów wymienionych powyżej.

Co znaczy zalogowanie? Otóż mniej więcej tyle:

Będziemy w stanie przejść do metody Index, która jest klasie wymagającej autoryzacji. Czyli User.Identity.IsAuthenticated zwróci TRUE. To całkiem fajnie. Oprócz tego, mamy kilka dodatkowych informacji:
Oraz widok:

W widoku widać że interesują nas cechy nadane nam przez system. Nie ważne czy to FB, Twitter, G+ czy my sami (AuthController, Login w wersji POST). Po uruchomieniu aplikacji wynik operacji wyglądają tak:

Wersja lokalna (user:jaroslaw/pass:stadnicki):

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier : jaroslaw
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name : jaroslaw

Wersja z G+

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier : 1#6#9#9#9#2#4#7#1#2#6 (odrobina prywatności)
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname : Jarosław
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname : Stadnicki
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name : Jarosław Stadnicki
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress : jaroslaw.stadnicki@gmail.com
urn:google:profile : https://plus.google.com/+JarosławStadnicki

Itp, itd. Warto zwrócić uwagę, że z G+ (inne też), dostajemy już identyfikator użytkownika, który możemy powiązać ze swoim lokalnie tworzonym kontem. I gdy ponownie przyjdzie gościu z G+ i się zaloguje się i dostaniemy jego ID, będziemy wiedzieć, że on to on, a nie ktoś inny.

Na koniec jeszcze ważna sprawa, oczywiście należy pamiętać aby samodzielnie stworzyć swoje aplikacje odpowiednio na stronach:
https://developers.facebook.com/
https://apps.twitter.com/
https://console.developers.google.com/home/dashboard

Należy także ustawić poprawnie callbacki w tych systemach, u mnie wartość które działały poprawnie to: http://www.xoxox.com

Ej, ale co to za dziwny adres? No tak tak, bo Twitter nie lubi localhost (FB i G+ sobie z tym radzą). Dlatego dla Twittera robi się wyjątek i należy zaatakować windows\sytem32\drivers\etc\host dopisać taką linijkę:

127.0.0.1         www.xoxox.com

Od tej pory www.xoxox.com będzie wskazywać na wasz komputer. Ale jeszcze! Należy na normalnym IIS dodać stronę i pokazać jej, że binarki leżą u was w źródłach. Dodać binding w IIS. I na końcu w Visual Studio przełączyć się z IIS express na normalnego i też korzystać z www.xoxox.com. Można też zignorować twittera i dla testów sprawdzić tylko FB i G+ i korzystać z IIS express na 127.0.0.1

Tyle, od tej pory ja i wy (jaka jest liczna mnoga od ono?) będziemy mogli w prosty sposób logować się społecznościami. Aplikacja dostępna jest pod linkiem:
https://bitbucket.org/jstadnicki/simplesociallogin

Kod do aplikacji zostały zmienione przed publikacją, także aby zadziałały należy wygenerować własne oraz podmienić. Projekt działa pod kontrolą pełnego IIS, to także należy/można zmienić.

To tyle. Życzę miłej zabawy.

Generator danych Faker.net

~ Jarosław Stadnicki ~ Leave a comment

Każdy z nas jest choć trochę leniwy. Jedni troszkę mniej, inni troszkę bardziej. Ja na ten przykład czasem się rozpędzam i piszę kod, który potrzebuje. Potem o nim opowiadam, a potem ktoś pyta czemu nie skorzystałem z jakiejś tam gotowej biblioteki. Wiem, że każdy z nas należy do mensy i wie, że ten wpis nie wziął się z powietrza.
Dzisiejszy wpis dedykuje koledze Ievgenowi (blog lub @ibezuglyi)(dla ktorego specjalnie załatwiłem sobie literki, żeby wpisać jego imię do komputera), który to pokazał mi Fakera – nie palec, ale taką bibliotekę. Służy ona do generowania różnych, ale skończonych, losowych danych.
Dane podzielone są tematycznie na:

  • ArrayFaker
  • BooleanFaker
  • CompanyFaker
  • DateTimeFaker
  • EnumFaker
  • InternetFaker
  • LocationFaker
  • NameFaker
  • NumberFaker
  • PhoneFaker
  • StringFaker
  • TextFaker
W każdej znajdą się ciekawe metody, które bardzo upraszczają, ułatwiają i przyspieszają tworzenie testów, lub przynajmniej losowych wpisów.
Nowy użytkownik w naszym serwisie to taki kod:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  var user = new UserAccount
   2:  {
   3:      Email = Faker.InternetFaker.Email() + Faker.NumberFaker.Number(),
   4:      Password = Faker.NumberFaker.Number(1000000000, 2000000000).ToString()
   5:  };

Ponieważ maile mogą się powtarzać, dodajemy jeszcze więcej losowości. Hasło nie przejdzie testów na trudność, ale będzie choć trochę losowe. Czaicie prostotę i moc? Następnym razem, gdy będziecie pisać własną bibliotekę do generowania losowych danych skorzystajcie z Fakera. A jak będziecie pisać inną bibliotekę, wcześniej skorzystajcie z googla LUB (znowu od Ievgena) http://nugetmusthaves.com.
Tym razem udało się krótko. Inne biblioteki warte polecenia?

EmptyResult na zły sposób

~ Jarosław Stadnicki ~ Leave a comment

Programując internety gdy wysyła się jakieś żądanie na serwer nie można założyć, że poleceni się po prostu wykona. Operacja void nie istnieje. Tzn można, ale to zła praktyka, można przecież wysłać żądanie i nie sprawdzić czy w ogóle doszło ono na serwer. Ale nie o to chodzi, mój przypadek polegał na tym, że wysyłać na serwer żądanie i chciałem tylko sprawdzić czy serwer to dostał czy nie. W moim przypadku wynik w ogóle nie był ważny. Naiwnie pomyślałem sobie, że wystarczy zwrócić (oczywiście w .net asp mvc) new EmptyResult() a na kliencie sprawdzić czy długość wyniku jest zero. Jak można się domyślić nie było by tego wpisu gdyby rzeczywistość nagięła się do mojego wyobrażenia.
Otóż pozytywny wynik operacji oraz długość wyniku była by zero gdybym wysłał request i ustawił dataType na script lub html. Ale nie w moim przypadku ja chciałem json. I co? Otóż biblioteka, która wrapowala żądania też była sprytna i czasem wysyłała żądanie json a czasem xml. I teraz operacja czasem działała gorzej a czasem jeszcze gorzej. Nie wiem czemu ubzdurałem sobie że EmptyResult coś zwróci i nie powinienem sprawdzić statusu odpowiedzi, zamiast zawartości PUSTEGO WYNIKU.

Ale jeśli jesteście ciekawi co odpowiada serwer na różne żądanie popatrzcie na ten przykładowy kod:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:  public class BlogController : Controller
   2:  {
   3:      [HttpGet]
   4:      public ActionResult Index()
   5:      {
   6:          return this.View("Index");
   7:      }
   8:   
   9:      [HttpGet]
  10:      public ActionResult CallMeToGetSuccessEmptyResult()
  11:      {
  12:          return new EmptyResult();
  13:      }
  14:  }

Następnie widok:

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #a31515; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}

.csharpcode .lnum { color: #606060; }

   1:   
   2:  <script src="~/Scripts/jquery-1.10.2.js"></script>
   3:  <div class="row">
   4:      @Html.ActionLink("By xml", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-xml", data_type_of_data = "xml", data_anchor_id = "#demo-container-xml" })
   5:      @Html.ActionLink("By json", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-json", data_type_of_data = "json", data_anchor_id = "#demo-container-json" })
   6:      @Html.ActionLink("By script", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-script", data_type_of_data = "script", data_anchor_id = "#demo-container-script" })
   7:      @Html.ActionLink("By html", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-html", data_type_of_data = "html", data_anchor_id = "#demo-container-html" })
   8:  </div>
   9:   
  10:  <div class="row">
  11:   
  12:      <div class="col-md-3">XML<div id="demo-container-xml"></div></div>
  13:      <div class="col-md-3">JSON<div id="demo-container-json"></div></div>
  14:      <div class="col-md-3">SCRIPT<div id="demo-container-script"></div></div>
  15:      <div class="col-md-3">HTML<div id="demo-container-html"></div></div>
  16:  </div>
  17:   
  18:  <script type="text/javascript">
  19:   
  20:      var showJson = function(data, status, anchor) {
  21:          $(anchor).html('');
  22:          var htmlToSet = "status: " + status + "<br/>";
  23:          if (data != null) {
  24:              htmlToSet += "data lenght: " + data.length;
  25:          } else {
  26:              htmlToSet += "data is null";
  27:          }
  28:              $(anchor).html( htmlToSet );
  29:      };
  30:   
  31:      var demoResult = function(e) {
  32:          e.preventDefault();
  33:          var href = $(e.target);
  34:          var data_type = href.data("type-of-data");
  35:          var anchor = href.data("anchor-id");
  36:          var ajaxOptions = {
  37:              url: '@Url.Action("CallMeToGetSuccessEmptyResult", "Blog")',
  38:              dataType: data_type,
  39:              success: function(data, status) {
  40:                  showJson(data, status, anchor);
  41:              },
  42:              error:function(data, status) {
  43:                  showJson(data, status, anchor);
  44:              }
  45:          };
  46:   
  47:          $.ajax(ajaxOptions);
  48:      };
  49:   
  50:      $(document).ready(function() {
  51:          $(".test-button").on("click", demoResult);
  52:      });
  53:   
  54:  </script>

I teraz na obrazu wyniki działania aplikaji:

Czyli nie zawsze EmptyResult to tylko “”, czasem to także parseerror gdy oczekujemy json. Na przyszłość polecam zastanowić się co się powinno sprawdzić, gdy nie chcemy nic sprawdzać. Oraz jak chce to sprawdzić.
Jak zawsze, chętnie popełnię kolejne błędy za was w następnym odcinku.

Czemu bugi są jak wino, im starsze tym droższe.

~ Jarosław Stadnicki ~ Leave a comment

Każdy z nas/was słyszał o tym, że naprawienie buga z czasem staje coraz droższe, a jak kod pójdzie na produkcje to już w ogóle wszystko drożej miliard razy. Każdy słyszał, ale czy ktoś zdaje sobie sprawę czemu tak się dzieje?
Mi wydaje mi się że wiem i chce się tą wiedzą podzielić, także posłuchajcie pewnej bajki o remoncie mieszkania, a może znajdziecie analogie do IT, a przy okazji może podpowiecie jak dobrze zainstalować progi w mieszkaniu.
Pewnego razu, pewien programista zapragnął mieszkania, takiego pięknego mieszkania, a w nim pomalowanych ścian i sufitów, kafelek i paneli. I chciał (on – programista) aby to ładnie było w nim (tym – mieszkaniu). Słuchy chodziły, że inni koledzy z fachu tego samego już maja takie cuda i że ładnie u nich. Poradził się więc do kogo pójść, aby piękna takie i w jego domu zagościły.
Gdy wszystko już się ustaliło i zrobiło, złoto przeszło z ręki do ręki, wprowadził się on ze swoją białogłową i ich kwiatem miłości do nowego pałacu.
Ich zdziwieniom i radości z posiadania własnego miejsca nie było granic. A w zasadzie były i dosyć szybko się skończyła piękna radość. Pomijając większe i mniejsze odstępstwa od umowy/jakości. Skupię się w tej bajce na rzeczy, która może się wydać wręcz śmieszna, a taka nie jest.
Otóż oto przedmiot wywodu mojego:
Próg

Śmiechy i chichy teraz cichną i lecimy dalej. Otóż piękne plany, które snuliśmy to ograniczenie progów do minimum. Tutaj nastąpił kontakt z rzeczywistością:
Jak to bez panel bez progów, muszą być!
Nieświadomi wiedzy pokiwaliśmy głowami, jak muszą to muszą – fachowiec wie. 0:1 dla niego, bo tak naprawdę to nie muszą.
Gdy w mieszkaniu byliśmy i mieszkaliśmy, naszła nas taka fanaberia, żeby drzwi posiadać, bo czasem warto się zamknąć w jednym z nich i spokój mieć. Progi jednak spokoju nam dać nie chciały. Trzeba było je poprawić. Pewnego weekendu, postawiłem się zebrać i poprawić to co nas boli. Zerwałem progi, tu i tam razem z panelu kawałkiem, ale to nie problem, da się to zakryć nowymi, bardziej płaskimi ale też trochę szerszymi. Aż tak to nie boli. Przy pierwszej próbie założeniu nowego progu okazało się, że nie pasuje i trzeba trochę poprawić

Gdy już przy pomocy próbnika i pilnika dopasowałem szczelinę, tak aby nowy, właściwy próg pasował, wiedziałem że poprawką dwóch następnych na pewno nie zajmie im chwileczki.
Drap drap, szlif szlif udało się zrobić tak, że próg 2.0 pasował do szczeliny 1.0, co mniej więcej wyglądało tak:

Na internetach znana jest taka oto przyśpiewka:

99 little bugs in the code

99 little bugs in the code
Take one down, patch it around
117 little bugs in the code

A wiadomo, tradycja rzecz święta, także tego:

Gdy i tutaj udało mi się dopasować szczelinę do próbnika, okazało się że próg 2.0 nie jest aż tak kompatybilny ze szczeliną i należy wprowadzić drobny tunning sprzętowy:

Wreszcie, gdy wszystkie szczeliny 1.0 zostały spasowane z progiem 2.0, mógł nastać czas relesu. Ale! Przecież jeszcze drzwi. Ktoś opowiadał, że progi po drzwiach, hmmm. Tutaj uratowało nas szczęście, postanowiliśmy zaczekać na monterów ościeżnic i drzwi, co okazało się dobrym posunięciem, bo “progi po drzwiach” – tak rzekł pan montujący.

Ja spędziłem cały dzień, zrywając starą wersję progu, dopasowując szczelinkę i dopasowując nowe progi, Nie mogłem zdjąć podłogi i normalnymi narzędziami ściąć wystających elementów. Nie posiadając także narzędzi czy jakieś specjalistycznej wiedzy (w zasadzie nic szczególnego wiedzieć nie trzeba, ale zawsze) musiałem wprowadzić zmiany już w istniejącym systemie. Ok dałem rade, będzie działać, nauczyłem się pewnie paru rzeczy, ale zajęło mi to dzień – a muszę jeszcze dopasować progi do ościeżnic.
Gdyby od razu zrobić dobrze, tak że nie trzeba by w ogóle poprawiać, mając możliwości do manewrowania panelami, mając narzędzia to zamiast całego dnia, moją robotę można zrobić w pięć minut. W dodatku nie doszło by do uszkodzenia materiału, czy kupowania czegoś co nie pasuje i trzeba to wyrzucić.

Wszystkim czym mogę i jak mogę podpisuje się pod tym obrazkiem.
PS.
Jestem po releasie na produkcje, ale syf. Jestem strasznie nie pocieszony tym, jak mi poszło. Nie wiem czy nie będzie trzeba robić, kolejnego fixa i znowu robić releasa na produkcje, z programi 3.0.
Czas pokaże. Mam nadzieję, że teraz już będziecie wiedzieć, czemu im później tym drożej.

ToBeImplemented reboot

~ Jarosław Stadnicki ~ Leave a comment

Projekty które robi się dla siebie mają pewna cechę, która jednocześnie jest czymś dobrym i złym. Taki pet-project można rozpoczynać milion razy i nikt nie robi z tego powodu afery – to plus, po milionowym rozpoczęciu szanse na zakończenie są małe – to minus.
Ja właśnie zwiększyłem cyferkę do 3, na szczęście nadal chce mi się to pisać. Rozpocząłem od nowa, bo strasznie pokomplikowałem sobie aplikację, to raz, i przy próbach prostowania doszedłem do wniosku, że chyba szybciej będzie napisać to jeszcze raz, bez takiej ilości magicznego pyłku, który użyłem wcześniej. A dwa, że nauczyłem się paru nowych rzeczy, które chciałem tutaj wykorzystać.
Tym sposobem zmierzam do warstw. O ile wcześniej dzieliłem projekt na proste części:


Jak widać, szaleństwa nie ma. Aplikacja (ASP MVC) korzysta z serwisów, serwisy z bazy oraz czasem z samych siebie (oczywiście przez interfejsy).
Ok, w zasadzie nie ma się czego czepiać, tak/nie? Mogło być lepiej, mogło być gorzej. Zamiast sześciu żółtych prostokątów, mógł być jeden. Zawsze powtarzam, że nie wolno porównywać się gorszym, pozostaje więc tylko czepiać się i szukać miejsca na poprawki.
Co skusiło mnie to tego, żeby to zmienić? W serwisach było w zasadzie wszystko co nie jest związane z bazą danych i z samym mvc, czyli: logika, mapowanie z model na view model, maile, hash, konta użytkowników, blablablabla, wszystko.
Czy to dobre? It depends. Jeśli robi się mały prosty projekt (taki książkowy), to może będzie to dobre rozwiązanie, jeśli robi się nowego fejsbuka to raczej nie, a przypominam, że już nie długo moja aplikacja zajmie jego miejsce – widzę i słyszę wasz śmiech, zobaczymy kto będzie się śmiać ostatni!

Co takiego pozmieniałem w swoim rozwiązaniu? Warstwy, więcej warstw, znacie to przysłowie, że każdy problem da się rozwiązań dodając kolejną warstwę abstrakcji?
Razem z tym zmieniłem także troszkę podejście do rozwiązywania zależności, które tworzę, wygląda mniej więcej tak:

Największe zmiany to wiele aplikacji które są wspierane, robię to żeby sprawdzić jak długo można utrzymywać wspólny kod, na razie bez cross-platform.
Idealnie jest aby aplikacje były maksymalnie lekkie, cała logika jest przeniesiona do części Bussines, która wykonuje właściwą pracę. W przypadku aplikacji WPF są jej dwa warianty, jeden oparty o Application.REST, drugi który referuje bezpośrednio do Bussines i działa “natywnie”.
Dodatkowo ważny jest brak zależności w poziomie, tzn. serwisy nie mogą zależeć od serwisów, infrastruktura od infrastruktury, czy biznes od biznesu. Poszczególne klasy w danej warstwach muszą być samodzielne, jeśli ma się pojawiać jakaś zależność, oznacza to że klasa chce wziąć na klatę zbyt dużą odpowiedzialność i że jest źle.
Prawdę mówiąc, jestem dopiero na początku tej drogi i wiem, że pojawią się bloczki (już są), które będą specyficzne dla poszczególnych aplikacji, ale jestem na to gotowy i na aktualnym stopniu mojej znajomości naszej programistycznej domeny jestem w stanie to zaakceptować.

TL;DR:
W projektach gdzie zależności są poziome, np. serwisA zależy od serwisuB są, złe. Dwa powody: może to prowadzić to zależności cyklicznych, oraz oznaczać to może, że jeden z nich ma za dużą odpowiedzialność, ponieważ część pracy przekazuje do sąsiada o którym nie powinien wiedzieć.
Słowo motywujące na dziś: nie bój się eksperymentować!

Ciekawy moich postępów czy rozwiązań, aktualny projekt możesz znaleźć tutaj:
https://jstadnicki.visualstudio.com/DefaultCollection/_git/ToBeImplemented
https://github.com/jstadnicki/tbi