Bây giờ tôi đang xem xét node.js và nó có ý nghĩa về hiệu suất (tôi nghiện tốc độ), nhưng tôi chưa hiểu sâu về nó lắm.
Hồ sơ, hồ sơ, hồ sơ. Đó là cách duy nhất để biết rằng việc tăng tốc của bạn đang có ảnh hưởng thích hợp. Bạn có thể đoán rằng nó đủ nhanh. Nhưng hầu hết mọi người thích tối ưu hóa sớm. Điều đó tệ hơn là chơi với chính mình trong một cuộc hẹn hò.
Tôi tự hỏi liệu node.js có thể thay thế hoàn toàn sự phát triển web điển hình của tôi trong C # và ASP.NET MVC hay không, liệu nó có tốt hơn khi bổ sung cho C # và ASP.NET MVC hay không, nếu có một số thứ chỉ nên "để yên một mình ".
Có trường hợp sử dụng cho / chống lại C # và node.js không?
Chắc chắn, nếu bạn đang ở trong một cửa hàng thường xuyên viết mã bằng C #, thì bạn nên sử dụng MVC (nó tốt hơn rất nhiều so với WebForms và được gọi là WebPages). Bạn sẽ không mất nhiều thời gian cho công cụ đào tạo, và đó là điều mà quy trình công việc của bạn nên xử lý.
Những gì bạn dường như không chỉ ra ở trên là lý do để chọn từng. Bạn đã đưa ra hai tùy chọn thị trường hiện tại, một vẫn ở giai đoạn Alpha, một là vào năm thứ ba phát hành nền tảng đầy đủ. Tôi sẽ không muốn so sánh các mẫu xe điện thử nghiệm hiện tại với các mẫu xe hybrid của Honda đã có mặt trên thị trường. Họ ở hai giải đấu khác nhau.
Bây giờ, đây là một lý do để bạn tránh xa node.js, nếu bạn trên danh nghĩa là một cửa hàng C #.
Bạn hiện không làm việc trong i / o sự kiện không đồng bộ, bạn hiện đang làm việc ở định dạng thủ tục.
Đó là phản đề cho những gì nodejs sẽ làm cho bạn.
Tuy nhiên, nếu bạn thường xuyên viết mã async bằng C # và bạn sử dụng nó rất nhiều theo kiểu sự kiện, thì có, node.js là để bạn cân nhắc mạnh mẽ.
Đây là những gì bạn sẽ từ bỏ:
IIS - Điều này thực sự quan trọng đối với nhiều người. Những thứ như tích hợp A / D bản địa đã được thực hiện và không có lỗi. Trên thực tế, node.js tích hợp tốt với IIS.- Tạo khuôn mẫu bằng dao cạo - Nếu bạn đã thực hiện bất kỳ C # MVC nghiêm túc nào, thì bạn đang sử dụng và yêu thích Dao cạo và bạn có thể tạo ra mọi thứ nhanh như thế nào. Có các mẫu tương tự trong nút và tôi chắc chắn không gõ nút, nhưng toàn bộ chuỗi công cụ đã có trong C # và rất nhiều mẫu hiện đang được xây dựng trong thế giới nút. NB: rất nhiều công cụ này bây giờ khá trưởng thành _
- xây dựng thời gian biên dịch của dlls - node.js thường được biên dịch nhanh chóng, nghĩa là không phải tất cả các đường dẫn đều được kiểm tra khi khởi động. Hoàn toàn có thể có mã thực sự xấu trong nút mà không ai từng chạm, kiểm tra hoặc kiểm tra.
- Tất cả các công cụ hiện được tích hợp vào VS mà bạn sử dụng hàng ngày - Không có nhiều hỗ trợ VS cho javascript. Một phần vì mọi thứ trong javascript rất năng động. Lưu ý: Microsoft rõ ràng đang làm việc về hỗ trợ công cụ cho javascript _
Đây là những gì bạn sẽ đạt được:
- tất cả mọi thứ bạn phát triển sẽ có cùng ngôn ngữ, giả sử bạn thực hiện kịch bản phía máy khách cũng như máy chủ. (hoặc tại sao bạn thậm chí sẽ xem xét javascript trên máy chủ)
Vì vậy, vì tôi dường như hoàn toàn làm hỏng Node ở đây, hãy để tôi chỉ ra rằng nút đó là ngôn ngữ chơi của tôi ở nhà, tôi yêu nó và đôi khi tôi giúp mọi người gỡ lỗi nó trên các máy chủ trò chuyện stackoverflow (phòng 642). Tôi thấy rằng nó có tiềm năng lớn và tuyệt vời trong tương lai.
Tôi chỉ nói, đừng vứt đứa bé ra và tự hỏi tại sao nước tắm lại bẩn.
Bạn đã không đưa ra một lý do tại sao bạn nên từ bỏ nhiều năm kinh nghiệm của mình và bắt đầu một cái gì đó mới. Là công cụ xấu? Không có gì. Cả hai đều tuyệt vời và làm cho sự phát triển một cách dễ dàng.
Nút có thể thay thế C #? Vâng, khá chắc chắn. PHP hoặc Java hoặc Ruby cũng vậy. Bạn không hỏi về những điều đó.
Đây là cách bạn biết khi bạn sẵn sàng lập trình node.js thay vì C #:
- Bạn đang xem xét viết một cuốn sách để giúp người khác "lấy javascript" thay vì các chương trình cũ nhàm chán mà họ đã viết trước đó trong C # và v.v.
- Bạn đã gặp sự cố với I / O đồng bộ (chặn) khiến ứng dụng của bạn không hoạt động thực sự.
- Bạn không sử dụng bất kỳ thư viện nào trong C # ngoài MVC mặc định và chỉ để định tuyến và bạn khá chắc chắn rằng mình có thể làm một công cụ định tuyến tốt hơn và bạn đang mã hóa mọi thứ gần với kim loại nhất có thể.
- Mỗi đối tượng dữ liệu bạn thiết kế bạn xem là một hàm băm thay vì một đối tượng được gõ mạnh.