Tôi có nên sử dụng ScriptSharp

Question

Tôi đang phát triển ứng dụng ASP.NET MVC đầu tiên của mình và tôi tin rằng Script # có thể giúp tôi rất nhiều. Nhưng nó không thể tìm thấy tài nguyên cần thiết để hỗ trợ sự phát triển của tôi.

Tôi không thể tìm thấy Trang web codeplex; Chỉ có một hướng dẫn, rất tốt, nhưng không đủ; Tôi có thể tìm thấy rất ít hướng dẫn; Tôi biết rằng Script # được sử dụng để phát triển các kịch bản ASP.NET MVC và rằng nguồn của MVC phân phối thư viện.

Nhưng có vẻ như nó chỉ được sử dụng trong nội bộ Microsoft.

Tôi có thể tìm tài nguyên khác ở đâu ???

Bạn có thực sự nghĩ rằng Script # sẽ được tiếp tục và các phiên bản mới sẽ được triển khai và nó nên được sử dụng bởi projetcs của bên thứ ba không ???

Cảm ơn trước

Answer 1

Đừng sợ Javascript, đó là một beautiful và powerful ngôn ngữ. Và với các khung như jQuery, Prototype và Dojo, thao tác DOM và AJAX được đơn giản hóa rất nhiều và các vấn đề đa trình duyệt chủ yếu là lịch sử.

Giới thiệu về tập lệnh #, tôi đồng ý với this answer by mcintyre321. Phát hành lần cuối hơn một năm trước + nguồn đóng = không đi cho tôi.

CẬP NHẬT Tháng 1/2010: đã có bản phát hành Script # mới kể từ khi viết bản gốc câu trả lời này. Nó vẫn là nguồn đóng nhưng tác giả đề cập đến việc mở nguồn của nó sau 1.0

CẬP NHẬT May 2011: Script# is now open source.

Answer 2

Tôi đang sử dụng jQuery. Nó thực sự là tốt. Nhưng tôi tin rằng nó là confortable hơn với tôi để làm việc với C#. Ngay cả khi nó là một tập hợp con.

Answer 3

Giống như những người khác, tôi muốn giới thiệu một số JavaScript (cụ thể là jQuery). Nếu bạn muốn tiếp tục với Script #, blog của Nikhil Kothari có thể là một tài nguyên tốt cho bạn. http://www.nikhilk.net/ScriptSharpIntro.aspx - Điều đó đang được nói, tôi nghĩ bạn sẽ thấy rằng bạn hiệu quả hơn với jQuery. Có một cơ sở dữ liệu lớn của các plugin được cộng đồng viết nên bạn sẽ không nhất thiết phải phát minh lại bánh xe trên mọi thứ bạn muốn làm. jQuery plugins instead of ASP.NET Controls

Answer 4

Tôi sử dụng Tập lệnh #, tôi nghĩ nó tuyệt vời. Bạn có thể sử dụng nó với bất kỳ khung công tác nào, jQuery, dojo bất cứ điều gì, tuy nhiên bạn sẽ phải đóng khung, điều này có thể là một công việc lớn ...

Nó chỉ mang lại lợi ích khi tôi thấy nó cho phép bạn phát triển javascript trong một môi trường được đánh máy mạnh mẽ. Tôi nghĩ rằng đây là một lợi ích rất lớn. Tôi từ chối phát triển trong các ngôn ngữ đánh máy yếu như bảo trì là một cơn ác mộng.

Nếu bạn muốn làm việc bằng ngôn ngữ đánh máy yếu thì bạn không cần Script #.

Answer 5

IMHO Script # chỉ phù hợp với các dự án lớn, với ứng dụng web thực sự "phong phú". Tham gia vào loại dự án như vậy, tôi chỉ có thể nói rằng Script # đã giúp chúng tôi rất nhiều. Nhận xét của josephhemingway về cách đánh máy mạnh mẽ là đúng 100% cho trường hợp như vậy. Nó cũng cho phép chúng tôi giới thiệu các nhà phát triển .NET mới mà không cần bất kỳ nền JS nào một cách nhanh chóng. Giả sử kế hoạch của Nikhil Kothari để mở nguồn vào mùa hè năm 2008, chúng tôi thậm chí còn bị dịch ngược (không nói cho ai biết! Nó bất hợp pháp) và giới thiệu generics, các toán tử quá tải, các sửa lỗi khác nhau, v.v.

NHƯNG. Sau đó, Script # hỗ trợ mờ đi. Dự án CodePlex với các cuộc thảo luận và theo dõi vấn đề đã được đóng lại (thú vị là các phần của khuôn khổ đã được xuất bản ở đó ngay trước đó). Không có cập nhật, không có kế hoạch tương lai, không có giải thích. Sau những điều như vậy tôi sẽ xem xét Script # chỉ sau khi nó đi nguồn mở để cung cấp cho khả năng cộng đồng để hỗ trợ nó. Ví dụ. trên CodePlex.

Answer 6

Bản phát hành đã ra mắt hôm nay, vì vậy, bạn sẽ thấy rằng nó vẫn hoạt động tốt.

Bất kể sự thiếu cập nhật trước đó và nó không được mở nguồn, tôi vẫn sẽ sử dụng nó trên js thuần túy. Bạn có thể ngừng sử dụng Script # bất cứ lúc nào và tiến xa hơn với js 'biên soạn' nếu bạn không thích nó.

Tôi đồng ý với bạn Val mặc dù nó thực sự chỉ phù hợp với các dự án lớn dựa trên js. Tôi không nghĩ rằng bạn sẽ nhận được nhiều lợi ích từ việc sử dụng nó để thực hiện chức năng trang cơ bản như xác thực đầu vào biểu mẫu, vv Nó có thể sẽ không có giá trị thiết lập nó lên.

Nếu tuy nhiên bạn đang sử dụng nhiều javascript và cần phải nhân rộng OOP thì tôi nghĩ rằng đó là điều phải. Những thứ như tái cấu trúc trở nên dễ dàng như vậy, với js đơn giản tôi sẽ không bao giờ tái cấu trúc bởi vì nó quá khó để thực hiện, theo thời gian, mã của tôi trở thành một mớ hỗn độn.

Wow Val bạn có generics để làm việc trong nó, tôi ấn tượng, là nó khó khăn? Hỗ trợ Generics sẽ là tuyệt vời, do đó, phương thức và toán tử sẽ bị quá tải. Bạn có chắc chắn rằng nó là bất hợp pháp để dịch ngược nó, tôi sẽ phải có một cái nhìn để xem nếu nó là các điều khoản sử dụng.

Answer 7

Wow Val bạn có generics để làm việc trong nó, tôi rất ấn tượng, có khó không? Hỗ trợ Generics sẽ tuyệt vời, vì vậy, sẽ là phương thức và quá tải toán tử. josephhemingway

Toàn bộ điểm là trình phân tích cú pháp của ScriptSharp hỗ trợ cú pháp C# 2.0 đầy đủ. Điều duy nhất cần thiết là tạo ra JS thích hợp. Không có nhiều công việc, xem xét JS năng động. Generics sẽ hoạt động như kiểu Java, nghĩa là không có thế hệ cho mỗi bộ đối số kiểu đóng, chỉ một lớp.

Bạn có chắc chắn rằng đó là bất hợp pháp để dịch ngược nó, tôi sẽ phải có một cái nhìn để xem nếu nó là các điều khoản sử dụng. josephhemingway

Đúng, đó là bất hợp pháp. EULA cho thấy trong thiết lập rõ ràng đề cập đến điều đó.

Answer 8

Tóm lại, câu trả lời của tôi là: nếu bạn thích các IDE mạnh mẽ chạy trên Windows, OOD và C#, hãy sử dụng ScriptSharp. Nó có thể duy trì và được cấu trúc tốt hơn và đủ ổn định để sử dụng cho các dự án nghiêm túc. Nó cũng có thể dễ dàng mở rộng, như minh họa dưới đây và bởi các dự án khác.

Vì đây là một chuỗi được lập chỉ mục khác của Google mà mọi người tham khảo Script # và jQuery là loại trừ lẫn nhau, tôi chỉ muốn chỉ ra một số người đang hợp nhất hai thế giới này và trong trường hợp của tôi giải phóng rất nhiều sức mạnh. Tôi đang cung cấp một thư viện hoàn toàn miễn phí và tái sử dụng để truy cập jQuery 1,4 từ Script # dự án, và mã nguồn đầy đủ cho các giải pháp mà tạo ra nó (hầu như chỉ từ file tài liệu API của jQuery):

http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp

Answer 9

Ngắn trả lời KHÔNG. Chờ cho TypeScript.

Kịch bản # thực sự tuyệt vời, nhưng MS đã quyết định không hỗ trợ nó. Lý do cho rằng hóa ra là họ đang làm việc trên một phiên bản tốt hơn - TypeScript (http://www.typescriptlang.org/) Nó thêm hỗ trợ cho tất cả mọi thứ bạn cần trong một ngôn ngữ tĩnh (intelliSense, kiểm tra kiểu, các giao diện, các lớp vv), nhưng vẫn trông rất giống JS, và quan trọng hơn - xác nhận tiêu chuẩn ECMA Script 6 sắp tới. (không giống như Tập lệnh # hoặc Dart của Google)

Answer 10

Ngoài ra, tôi muốn thêm rằng bạn chắc chắn nên sử dụng ScripSharp khi bạn dự định phát triển các dự án đa nền tảng. Ví dụ, hiện tại tôi viết mã thư viện xử lý hình ảnh của mình cho các nền tảng .NET, JavaScript (ScriptSharp), Android (Mono) trên C#. Ngoài ra tôi đang lên kế hoạch chuyển mã của tôi trên iOS (Mono) và Windows Phone trong tương lai. Và tôi nghĩ rằng nó tái sử dụng mã tuyệt vời và giảm thiểu thời gian phát triển!

Answer 11

Ưu điểm khác của việc sử dụng ScriptSharp mà không ai đề cập là nếu bạn cần tương tác với C# (sử dụng AJAX/REST/SOAP), bạn có thể sử dụng cùng một định nghĩa lớp ở cả hai nơi và đảm bảo rằng bạn có giao diện được định nghĩa đúng, bởi vì đó là cùng một tệp nguồn! Tôi đã cố gắng sử dụng logic trong các tập tin nguồn được chia sẻ với thành công tối thiểu do cách corelib của ScriptSharp không tương thích 100% với C# corelib. Nhưng nó hoạt động tốt cho các định nghĩa tệp dữ liệu.