Których technologii związanych z .NET się uczyć?

Nie uczyłem się za dużo technologii w obrębie .net w zasadzie to tylko EF i asp.net
Głównie pytam o: WPF, Windows Forms, ADO.NET. Czy warto sobie zaprzątać tym głowę czy kierować się bardziej w ASP.NET. Dosyć dobrze umiem programować w czystym c# i pora zabrać się za inne rzeczy. Chodzi mi o użyteczność w przyszłej mam nadzieję pracy jako junior której będę powoli szukać. Głównie interesuję się backendem aczkolwiek również js jest w moim obrębie zainteresowań.

Jeżeli backend to zainteresuj się jakimś narzędziem ORM czyli np. nHibernate albo Entity Framework. Dodatkowo możesz zainteresować się wykorzystaniem jakiegoś kontenera IoC np. Ninject'a albo Unity, bo to bardzo się przydaje. Co jeszcze mogę powiedzieć... Ja tam wolę programowanie na desktop niż web ale realia są takie, że dzisiaj web wygrywa. Zawsze możesz ciągnąć obie rzeczy WPF + MVVM oraz ASP.NET + MVC. Uczyłem się tak swego czasu i wcale nie jest to jakoś męczące, bo te dwa podejścia, czytaj wzorce mają ze sobą wiele wspólnego.

Wiesz... możesz pobawić się jeszcze w testowanie za pomocą nUnit czy wbudowanego w VS narzędzia.

WPF/UWP - tak, jeżeli aplikacje desktopowe/mobilne;
WinForms - tak, jeżeli utrzymanie starszych aplikacji desktopowych;
ADO.NET - chyba nie;
Entity Framework - tak;
.NET Core + ASP.NET Core - docelowo tak, na razie trudno powiedzieć.

ASP.NET - tak, jeżeli aplikacje webowe. Których jest większość w .NET dzisiejszym chyba.

Dzięki, w takim razie utwierdziłem się raczej że trzeba iść w stronę asp.net, umiejętności w front-endzie w tym przypadku też są podążane? I czy kontenery IoC są również wykorzystywane w web-devie?

IoC jak najbardziej np. w ASP.NET w MVC. Możesz wstrzykiwać klasy serwisowe, za pomocą ich interfejsów do kontrolerów itp.. Bardzo przydane.

Peres955 napisał(a):

Dzięki, w takim razie utwierdziłem się raczej że trzeba iść w stronę asp.net, umiejętności w front-endzie w tym przypadku też są podążane?

Często tak.

I czy kontenery IoC są również wykorzystywane w web-devie?

Nie ma znaczenia, jakiego rodzaju aplikacje piszesz, i tak masz zależności, którymi trzeba zarządzać.
No chyba, że wszystko piszesz w jednej metodzie. ;)

A ADO.NET trzeba znać. Programista, który nie umie korzystać z SqlConnection, SqlCommand i SqlDataReader i do każdej prostej operacji chce zaprzęgać ORMa, to upośledzony programista.

Dziękuję wszystkim, dużo mi podopowiedzieliście.

A ADO.NET trzeba znać. Programista, który nie umie korzystać z SqlConnection, SqlCommand i SqlDataReader i do każdej prostej operacji chce zaprzęgać ORMa, to upośledzony programista.

Upośledzony to właśnie korzysta z ADO pisząc masę bzdurnego i trudnego do utrzymania kodu. Nie trzeba od razu stosować wielkich ORM, jest np. Dappe i świetnie się sprawdza w prostych zapytaniach z parametrami.

dotnerd napisał(a):

Upośledzony to właśnie korzysta z ADO pisząc masę bzdurnego i trudnego do utrzymania kodu. Nie trzeba od razu stosować wielkich ORM, jest np. Dappe i świetnie się sprawdza w prostych zapytaniach z parametrami.

Niech zgadnę - jesteś seniorem z trzyletnim stażem?

Nikt tu nie pisał o używaniu ADO zamiast ORMa. Sytuacja, w której ktoś potrzebuje wywołać jedną procedurę składowaną, albo odpytać jedna tabelę i dołącza w tym celu ORMa do projektu - to jest właśnie upośledzenie programistyczne.

Sama znajomość ADO.NET przydaje się, bo:

1. Nie zawsze jest sens dołączania do projektu kolejnej biblioteki.
2. Żaden ORM nigdy nie będzie tak wydajny w operowaniu na bazie jak ADO.NET.
3. Nie każda aplikacja potrzebuje ORMa.
4. Niektóre aplikacje powstawały w czasach bez ORMów i są nadal utrzymywane.

A jakie ORM-y polecacie i co do testów (jeśli chodzi oczywiście o ASP.net MVC)?

ja sie z kolega zgodze :) jak sie uczylem pierwszego ORMa (LINQ) bylem w niebowizety ;) a potem (w pracy) wiele razy widzialem zalety wykorzystania klasycznego ADO. Nawet wydajnosciowo >byla roznica (mimo ze wiele czytalem o optymalizowaniu i cacheowaniu zapytan). Szacowalbym ze 90% to ORM ale 10% to klasyczne DBCommand ;) Generalnie ...nie trzeba byc mistrzem w >ADO, ale dobrze znac. na pewno NIE jest to zbedna wiedza. Ale zbyt duzo czasu tez nie warto temu poswięcać.

OK, ja czytałem że nie powinno się mieszać (w jednym projekcie) ORM i własnych odwołań do bazy przez ADO / DBCommand? Zgadzacie się z tym?

A jakie ORM-y polecacie i co do testów (jeśli chodzi oczywiście o ASP.net MVC)?

Co do ORM to za wielkiego wyboru nie ma, jeśli weźmiemy pod uwagę dużych graczy to pozostaje tylko EntityFramework i nHibernate, choć ja osobiście skłaniam się ku pierwszemu.
Jeśli chodzi o testy, osobiście używam nUnit - bo znam go od dawna i jest tam wszystko co potrzebuje. Jakiś czas temu była fala na xUnit - nie wiem jak teraz.

OK, ja czytałem że nie powinno się mieszać (w jednym projekcie) ORM i własnych odwołań do bazy przez ADO / DBCommand? Zgadzacie się z tym?

Ja nie jestem zwolennikiem mieszkania dostępu do bazy danych, ale nie ma też co sobie życia utrudniać. Np. jeśli wolisz pisać w ADO a dodatkowo np. chcesz użyć gotowego w MVC zarządzania użytkownikami, które pod spodem używa EntityFramework - to czemu nie.

Co do walki ORM - ADO. Ja jestem zwolennikiem tylko i wyłącznie ADO. Miałem wiele podejść do ORM i zawsze rzucałem złymi słowami pod nosem, bo natrafiałem na problemy wydajnościowe lub rzeczy których nie mogłem wykonać (np. with ties - tzn można obejść, ale współczuje bazie która musi wykonywać tego potwora [zapytanie sql]). Z drugiej strony czyste ADO to strata czasu programisty, dlatego polecam nakładki. Od ponad roku współpracuję z Dapperem i dla mnie oraz całego mojego zespołu to jest optymalne rozwiązanie.

Krzywy Ogórek napisał(a):

OK, ja czytałem że nie powinno się mieszać (w jednym projekcie) ORM i własnych odwołań do bazy przez ADO / DBCommand? Zgadzacie się z tym?

Ale czemu nie? Narzędzia się dobiera do celu. Typowe zadania można wykonać ORMem, a te wymagające większej wydajności, albo po prostu trudne do zrealizowania ORMem, można wykonać za pomocą ADO.NET albo nawet napisać w SQL. Grunt to zdrowy rozsądek.

Szalony Rycerz napisał(a):

Miałem wiele podejść do ORM i zawsze rzucałem złymi słowami pod nosem, bo natrafiałem na problemy wydajnościowe lub rzeczy których nie mogłem wykonać (np. with ties - tzn można obejść, ale współczuje bazie która musi wykonywać tego potwora [zapytanie sql]).

No, ale ORM nie służy do pisania "potwornych zapytań". with ties sugeruje robienie jakichś raportów, a ORM to nie są narzędzia do raportowania.

Szalony Rycerz napisał(a):

Co do walki ORM - ADO. [...] Od ponad roku współpracuję z Dapperem i dla mnie oraz całego mojego zespołu to jest optymalne rozwiązanie.

Bo Dapper to przecież nie ORM...

Tak czy siak, duże ORMy to po pierwsze narzędzia do budowy frameworków, po drugie do zastosowania w dużych projektach, po trzecie projektach programistycznych - czyli tych, w których pisze się kod, a nie bazę danych. Trzeba ich też umieć używać (warto przeczytać instrukcję), oraz stosować architekturę, która pozwala na ich efektywne wykorzystywanie. I robiąc cokolwiek, trzeba się zastanowić, czy w tym konkretnym przypadku, ORM jest faktycznie najprostszym wyjściem. Bo programiści często rzucają się na ORMy jak szczerbaci na suchary, i próbują z nich robić narzędzia do integracji, raportowania, przetwarzania wsadowego, itd. A ORM to po prostu narzędzie do generowania bazy z kodu oraz operacji CRUD, z paroma dodatkowymi bajerami.