Jakie dalsze kroki w nauce Backend-u w technologii .Net

Cześć, otóż mamy dylemat dotyczący tego, jak dalej rozdysponować swoje zasoby czasowe na naukę związaną z Backend-em w technologii .Net.
Dorzeczy. Jak do tej pory ogarnąłem:

• WebApi
• EF
• Linqu
• Testy jednostkowe i integracyjne
• Git/GitBash
• podstawy JS, Html i CSS

Obecnie powoli kończę naukę wzorów projektowych i powoli zaczynam się zastanawiać za co dalej się chwycić. Mamy dylemat między MVC (rozwiązanie już chyba rzadko stosowane w nowych projektach), a RabitMq i CQRS-em. A może powinienem skupić się na innych zagadnieniach.

Na czym wg waszego doświadczenia najlepiej obecnie się skupić?

Po cholerę Ci CSS/HTML na backendzie? Inna sprawa, że na juniora może Ci to starczyć, ale roboty w tym roku raczej i tak nie dostaniesz

Podstawy tak. Choć do pewnych faz developmentu. Mastering nie

@Escanor16 Chcę wiedzieć co się dzieje we froncie. Zresztą ogarnięcie podstaw frontu nie kosztowało mnie mega dużych nakładów czasowych

DDD, Clean Architecture, Mikroserwisy

rjakubowski napisał(a):

DDD, Clean Architecture, Mikroserwisy

Mówisz aby odpuścić sobie MVC ?

@Michał Jasiński:

Napisałeś że ogarniasz WebApi, a teraz pytasz czy odpuścić MVC?

dafuck, to tak jakby zdać prawko i pytać czy musisz się nauczyć odpalać samochód

WeiXiao napisał(a):

@Michał Jasiński:

Napisałeś że ogarniasz WebApi, a teraz pytasz czy odpuścić MVC?

dafuck, to tak jakby zdać prawko i pytać czy musisz się nauczyć odpalać samochód

A tak z ciekawości. Kiedy ostatnio stworzyłeś jakiś nowy projekt w oparciu MVC?

@Michał Jasiński:

Za każdym razem gdy nie potrzebuje czegoś dynamicznego.

Zresztą, jeżeli chodzi o sam przepływ requesta w MVC - to czy tak ogromną różnice robi czy zwrócisz return Ok(data), a return View(data)?

Jakby na architekturę aplikacji nie powinno to mieć znaczącego wpływu

Aczkolwiek przyznam że nie sądziłem że chodzi Ci o składnie np. Razora, a bardziej o podział warstw, mój błąd.

Więc jeżeli nie chcesz klepać widoków (Razor), to możesz się raczej obejść bez tego.

@{
    string message = "foreignObject example with Scalable Vector Graphics (SVG)";
}

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
    <rect x="0" y="0" rx="10" ry="10" width="200" height="200" stroke="black" 
        fill="none" />
    <foreignObject x="20" y="20" width="160" height="160">
        <p>@message</p>
    </foreignObject>
</svg>

WeiXiao napisał(a):

@Michał Jasiński:

Za każdym razem gdy nie potrzebuje czegoś dynamicznego.

Zresztą, jeżeli chodzi o sam przepływ requesta w MVC - to czy tak ogromną różnice robi czy zwrócisz return Ok(data), a return View(data)?

jakby na architekturę aplikacji nie powinno to mieć znaczącego wpływu

Aczkolwiek przyznam że nie sądziłem że chodzi Ci o składnie np. Razora, a o sam koncept MVC.

Więc jeżeli nie chcesz klepać widoków (Razor), to możesz się raczej obejść bez tego.

@{
    string message = "foreignObject example with Scalable Vector Graphics (SVG)";
}

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
    <rect x="0" y="0" rx="10" ry="10" width="200" height="200" stroke="black" 
        fill="none" />
    <foreignObject x="20" y="20" width="160" height="160">
        <p>@message</p>
    </foreignObject>
</svg>

Zdaje się, że nie wyraziłem się dostatecznie precyzyjnie. Dokładnie, nie chodzi mi o sam koncept MVC, a o tworzenie aplikacji internetowych które mają jednocześnie interfejs użytkownika zwracany przez Razor oraz logikę biznesową

Generalnie wydaje mi się że ten temat sam w sobie nie jest duży

Myślę że jakbyś machnął zwykłego CRUDa todo list i doczytał jak działa tam np. model binding (szczególnie np. przypadki z dynamicznymi formularzami) https://www.learnrazorpages.com/razor-pages/model-binding albo ogólnie przeczytał to co jest na tej stronce i ewentualnie w docsach

to nie zajęłoby ci to dużo godzin, a byś się sensownie orientował w temacie

WeiXiao napisał(a):

Generalnie wydaje mi się że ten temat sam w sobie nie jest duży

Myślę że jakbyś machnął zwykłego CRUDa todo list i doczytał jak działa tam np. model binding (szczególnie np. przypadki z dynamicznymi formularzami) https://www.learnrazorpages.com/razor-pages/model-binding albo ogólnie przeczytał co to jest na tej stronce i ewentualnie w docsach

to nie zajęłoby ci to dużo godzin, a byś się sensownie orientował w temacie

Brzmi sensownie. Dzięki za podpowiedź

A czy oprócz nauki technologii, to stworzyłeś jakieś własne sensowne projekty? Albo czy jest jakaś technologia, którą poznałeś faktycznie głębiej?

Mogę się mylić, ale po pierwszym poście to mam wrażenie, że przeskakujesz tylko po technologiach i rzeczach do nauki, a niczego nie zgłębiasz mocniej (bo jak zgłębiać z podejściem kończę naukę A i powoli zaczynam się zastanawiać za co dalej się chwycić. Mam dylemat między B, C i D).

LukeJL napisał(a):

A czy oprócz nauki technologii, to stworzyłeś jakieś własne sensowne projekty? Albo czy jest jakaś technologia, którą poznałeś faktycznie głębiej?

Mogę się mylić, ale po pierwszym poście to mam wrażenie, że przeskakujesz tylko po technologiach i rzeczach do nauki, a niczego nie zgłębiasz mocniej (bo jak zgłębiać z podejściem kończę naukę A i powoli zaczynam się zastanawiać za co dalej się chwycić. Mam dylemat między B, C i D).

Trudno zgłębiać szczegóły danej technologię jeśli nie wiadomo jakie ma się braki. Aby je określić musiał bym skonfrontować się z programowaniem komercyjnym. Wiedza którą posiadam pozwala mi na pisanie WebApi i tak owe apki mam stworzone.
Poza tym moja filozofia nauki (nie tylko w programowania) polega na zdobywaniu wiedzy od ogółu do szczegółu. Dzięki temu buduje sobie zrozumienie całości. Nie widzę sensu wgryzać się w detale jakiegoś zagadnienia przez dziesiątki godzin jeśli nie ma się pojęcia ogólnego o innych równie ważnych zagadnieniach. Innymi słowy wchodzeniem w szczegóły zajmuje się przy kolejnych iteracjach nauki.
Aby lepiej zobrazować moje podejście to przykładowo ucząc się WebApi ogarniam wszelkie podstawowe zagadnienia związane z autoryzacją, autentykacją, logowaniem do plików, paginacją i pewnie jeszcze parę innych. Zdaje sobie jednak sprawę że są jeszcze takie rzeczy jak wersjonowanie, metryki, testy wydajnościowe, CQRS ale to zostawiam sobie na później, a czas spożytkować na inne zagadnienia. A jest tego sporo bo i DDD, EventSorcig, Dockery itd. Na te tematy poza tym, że wiem do czego to służy nie mogę nic więcej powiedzieć.

Poza tym moja filozofia nauki (nie tylko w programowania) polega na zdobywaniu wiedzy od ogółu do szczegółu.

Myślę, że na oba podejścia jest miejsce.

Szybkie zeskanowanie wielu rzeczy pozwala na pobieżną orientację i na wiedzę "co jest do czego". Np. zanim się człowiek nauczy RabbitMQ czy Dockera warto wiedzieć, po co to w ogóle jest, co to są kolejki, kontenery.

Z kolei konkretny namacalny projekt pozwala na wejście głębiej. Pewne rzeczy wydają się proste, dopóki nie spróbujesz samemu. A czasem dopiero nabierają sensu w projektach (np. wzorce projektowe - można się uczyć na sucho, ale to mija się z celem, jeśli nie będzie się tego stosować).

Na czym wg waszego doświadczenia najlepiej obecnie się skupić?

na portoflio w githubie i znalezieniu pracy