Wykonuję sporo pracy z ASP.NET (C #, MVC), ale większość z nich to typowe tworzenie stron internetowych. Robię architekturę Restful przy użyciu repozytoriów CRUD. Większość moich klientów nie ma wielu zaawansowanych wymagań w swoich aplikacjach.

Teraz patrzę na node.js i jego wpływ na wydajność (jestem uzależniony od prędkości), ale nie zagłębiłem się w to aż tak bardzo.

Zastanawiam się czy

• node.js może realistycznie zastąpić mój typowy rozwój sieci w C # i ASP.NET MVC (nie przepisując istniejących aplikacji, ale pracując nad nowymi)
• node.js może uzupełnić aplikację ASP.NET MVC, dodając trochę asynchronizacji do istniejącej architektury.

Czy istnieją przypadki użycia dla / przeciwko C # i node.js?

Edytować

Uwielbiam ASP.NET MVC i jestem bardzo podekscytowany tym, dokąd zmierza. Próbuję tylko sprawdzić, czy istnieją specjalne przypadki użycia, które sprzyjałyby node.js

Teraz patrzę na node.js i jego wpływ na wydajność (jestem uzależniony od prędkości), ale nie zagłębiłem się w to aż tak bardzo.

Profil, profil, profil. To jedyny sposób, aby wiedzieć, że twoje przyspieszenia mają odpowiedni wpływ. Można się domyślić , że jest wystarczająco szybki. Ale większość ludzi lubi przedwcześnie optymalizować. To gorsze niż zabawa ze sobą podczas randki.

Zastanawiam się, czy node.js może całkowicie zastąpić moje typowe tworzenie stron internetowych w C # i ASP.NET MVC, czy jest to lepsze jako uzupełnienie C # i ASP.NET MVC, czy też są pewne rzeczy, które powinny po prostu „zostawić wystarczająco dobrze w spokoju „.

Czy istnieją przypadki użycia dla / przeciwko C # i node.js?

Oczywiście, jeśli jesteś w sklepie, który rutynowo pisze kod w C #, powinieneś użyć MVC (jest znacznie lepszy niż WebForms i nazywa się WebPages). Nie stracisz dużo czasu na szkolenie w zakresie narzędzi i jest to coś, z czym Twój przepływ pracy powinien już sobie poradzić.

To, czego nie sugerujesz powyżej, jest powodem wyboru każdego z nich. Podałeś dwie aktualne opcje rynkowe, jedną wciąż w fazie Alfa, drugą w trakcie pełnego trzeciego roku wydania platformy. Nie chciałbym porównywać obecnie testowanych modeli samochodów elektrycznych z hybrydami Hondy, które są już na rynku. Są w dwóch różnych ligach.

Oto powód, dla którego trzymaj się z dala od node.js, jeśli jesteś nominalnie sklepem C #.

Obecnie nie pracujesz w asynchronicznych zdarzeniach we / wy, obecnie pracujesz w formacie proceduralnym.

To jest antyteza tego, co Nodejs zrobi dla ciebie.

Jeśli jednak często piszesz kod asynchroniczny w języku C # i używasz go często w stylu opartym na zdarzeniach, to tak, należy rozważyć node.js.

Oto, co zrezygnujesz:

• IIS - jest to naprawdę ważne dla wielu osób. Rzeczy takie jak natywna integracja A / D są już wykonane i całkiem wolne od błędów. W rzeczywistości node.js teraz dobrze integruje się z IIS.
• Szablony Razor - Jeśli wykonałeś poważny C # MVC, to używasz i kochasz Razor i jak szybko możesz wyrzucać rzeczy. Istnieją podobne szablony w węźle i na pewno nie pukam węzła, ale cały zestaw narzędzi jest już obecny w języku C #, a wiele z nich jest obecnie budowanych w świecie węzłów. Uwaga: wiele z tych narzędzi jest teraz dość dojrzałych _
• budowanie bibliotek dll w czasie kompilacji - node.js zazwyczaj jest kompilowany w locie, to znaczy nie wszystkie ścieżki są sprawdzane podczas uruchamiania. Zupełnie możliwe jest posiadanie naprawdę złego kodu w węźle, którego nikt nigdy nie dotyka, nie sprawdza ani nie testuje.
• Wszystkie narzędzia obecnie wbudowane w VS, których używasz na co dzień - Po prostu nie ma tak dużej obsługi VS dla JavaScript. Częściowo dlatego, że wszystko w javascript jest tak dynamiczne. Uwaga: Microsoft oczywiście pracuje nad obsługą narzędzi dla javascript _

Oto, co zyskasz:

• wszystko, co opracujesz, będzie w tym samym języku, zakładając, że wykonujesz skrypty po stronie klienta, a także po stronie serwera. (lub dlaczego w ogóle rozważyć javascript na serwerze)

Ponieważ wydaje mi się, że całkowicie wkurzam tutaj Node, pozwólcie, że zwrócę uwagę, że ten węzeł jest moim językiem gry w domu, uwielbiam go i pomagam ludziom debugować go czasami na serwerach czatów z przepływem stosów (pokój 642). Widzę, że ma w przyszłości wielki i niesamowity potencjał.

Mówię tylko: nie wyrzucaj dziecka i nie zastanawiaj się, dlaczego woda w wannie jest brudna.

Nie podałeś powodu, dla którego powinieneś porzucić swoje wieloletnie doświadczenie i zacząć od czegoś nowego. Czy albo złe narzędzia? Ani trochę. Oba są świetne i sprawiają, że rozwój jest dziecinnie prosty.

Czy węzeł może zastąpić C #? Tak, z całą pewnością. Podobnie PHP, Java lub Ruby. Nie pytasz o to.

Oto, w jaki sposób wiesz, kiedy możesz zaprogramować node.js zamiast C #:

• Zastanawiasz się nad napisaniem książki, aby pomóc innym ludziom „dostać javascript” zamiast nudnych starych programów, które napisali wcześniej w C # i itp.
• Masz problemy z synchronicznym (blokowaniem) we / wy, uniemożliwiającym aplikacjom wykonywanie rzeczywistej pracy.
• Nie używasz ŻADNYCH bibliotek w języku C # innych niż domyślny MVC i to tylko do routingu, i jesteś prawie pewien, że możesz zrobić lepszy silnik routingu i kodujesz wszystko tak blisko metalu, jak to tylko możliwe.
• Każdy projektowany obiekt danych widzisz jako skrót zamiast silnie wpisanego obiektu.

Jeśli po prostu robisz spokojną architekturę przy użyciu repozytoriów CRUD, nie ma dobrego powodu, aby przenieść istniejącą aplikację do node.js.

Jeśli piszesz nową aplikację, która obsługuje REST i CRUD, mogą istnieć dobre powody, aby używać node.js od samego początku.

To zależy od aplikacji.

Na przykład osobiście pisałbym aplikacje REST / CRUD w pełni w node.js, ponieważ jest to osobiste preferencje. Węzeł świetnie się rozwija, ASP.NET MVC było dla mnie irytującym ograniczeniem.

Werdykt: Oba narzędzia wykonują zadanie. Jeśli nie ma określonych wymagań, które faworyzują platformę .NET lub węzeł, użyj dowolnej opcji. tzn. to osobiste preferencje.

Mogę jednak wymienić niektóre zalety obvouis obu platform

ASP.NET

• Integracja z Windows / .NET. Jeśli chcesz, aby stos Microsoft był ściśle powiązany i wysoce zintegrowany, to potrzebujesz .NET
• łatwo dostępna siła robocza
• Monolityczne ramy, które trzymają cię za rękę
• Ma zestaw funkcji, które działają od razu po wyjęciu z pudełka. Jeśli jesteś zadowolony z tych funkcji, poprawia wydajność. Jeśli zamiast tego chcesz mieć niestandardowe funkcje, walczysz z narzędziem i zmniejszasz produktywność.

Node.js

• Jeden język dla całego stosu internetowego (jeśli używasz baz danych noSQL, które używają js do swoich „zapytań”, takich jak couch / mongo).
• Idealne do miękkich aplikacji internetowych w czasie rzeczywistym za pomocą narzędzi takich jak socket.io
• Idealny do klejenia w sieci, gdy wszystko, co robi twój serwer, to rozmowa z n zdalnymi punktami końcowymi różnych typów.
• Daje ci tylko minimalne funkcje od razu po wyjęciu z pudełka. Oznacza to, że możesz zbudować swoją aplikację w wysoce spersonalizowany sposób.
• Zbiór małych narzędzi w stylu uniksowym, które wykonują jedną i jedną rzecz dobrze, które można łatwo łączyć ze sobą
• npm : poprawne zarządzanie pakietami
• bogata społeczność Open Source