Tại sao thế giới .NET không có bất cứ thứ gì như rails / grails / django / roo? [đóng cửa]


10

Dường như với tôi rằng các nền tảng web phát triển nhanh chóng sẽ thay đổi hoàn toàn thế giới của các ứng dụng web.

Đã năm năm kể từ khi Rails 1.0 được phát hành cho Ruby và kể từ đó chúng ta đã thấy Grails cho Groovy, Django cho Python và Roo cho Java.

Nhưng theo hiểu biết của tôi (có lẽ là hạn chế, là một trình phát triển Java / Groovy) thì không có khung tương tự cho C #.

Có một điều như vậy tồn tại? Nếu không, tai sao không?

Chỉnh sửa: Hoàn toàn có thể Tôi không sử dụng đúng từ khi tôi nói "phát triển nhanh", nhưng tôi đang nói về các khung có thể hình dung cho phép bạn xây dựng một công cụ blog hoạt động trong 30 phút. Bạn không thể làm điều này một cách hợp lý với, giả sử, Java, Spring và Hibernate, được cung cấp cấu hình khác nhau cần thiết để cho phép các bộ điều khiển của bạn được tìm thấy, cả cấu hình và mã cần thiết cho các thực thể của bạn tồn tại và được truy xuất.

Vì vậy, tôi đang nói về các khung xử lý tất cả CRUD với tâm lý cấu hình quá mức. Nếu ai đó có những từ thích hợp cho những gì tôi đang nói, hãy cho tôi biết.

Câu trả lời:


5

Dường như với tôi rằng chưa có tên cho loại khung này mà tất cả các bạn đang nói về chủ đề này. Tôi gọi chúng là các Khung giống như RAILS : Các khung làm tăng năng suất bằng cách phối hợp các khung hiện có khác với mục đích giải quyết các nhu cầu cơ bản của hầu hết các ứng dụng web, nhưng đồng thời che giấu tất cả sự phức tạp từ nhà phát triển.

Theo nhu cầu cơ bản, ý tôi là việc triển khai Nhà cung cấp kiên trì, Container phụ thuộc phụ thuộc, Công cụ ghi nhật ký, nền tảng MVC, Công cụ mẫu HTML, Bộ khởi tạo mẫu trang web với các cài đặt CSS, Khung bảo mật và một số Thư viện Javascript cho các tính năng AJAX và những thứ tuyệt vời khác. Các khung giống như RAILS phối hợp tất cả các khung và công cụ này trên cơ sở mô hình Miền (các thực thể trong hệ thống của bạn với các thuộc tính của nó).

Nhờ nguyên tắc Cấu hình trên cấu hình, các khung này tránh được nhu cầu xác định nhiều tệp cấu hình thường được yêu cầu bởi các khung mà chúng phối hợp (như Spring, Spring MVC, Hibernate, Log4J, v.v.), giả định các cấu hình theo mặc định dựa trên việc đặt tên , cấu trúc và siêu dữ liệu được bao gồm trong cùng một định nghĩa lớp.

Nhờ các ngôn ngữ động mà các khung công tác này sử dụng (như Ruby, Groovy, Python, Clojure, v.v.), ngoại trừ SpringRoo thực hiện hành vi động trong Java bằng cách sử dụng AspectJ, chức năng thuộc về các khung bên dưới được mở rộng và được cung cấp cho nhà phát triển một cách đồng bộ và thanh lịch đến mức anh ấy / cô ấy chỉ nhận thức được các công nghệ cơ bản.

Cuối cùng, nhờ vào kỹ thuật Scaffold, các bài kiểm tra đơn vị, kiểm tra tích hợp, bộ điều khiển và khung nhìn được tạo tự động cho các chức năng chính (CRUD) trên mỗi một trong các đối tượng miền được xác định bởi nhà phát triển.

Trong thế giới .NET, chưa có gì được phát triển, tuân theo tất cả các định nghĩa trước đó. Nhưng không có gì ngăn cản điều đó xảy ra sớm. Có các khung, công cụ và thư viện tuyệt vời đã có sẵn trong thế giới .NET có thể được phối hợp bởi một khung giống như RAILS mới được tạo cho CLR. Có Unity, Spring.NET và Castle Windsor trong số những người khác cho các nhu cầu Inyection Inyection. Entity Framework 4, NHibernate và iBatis.NET là các Nhà cung cấp .NET Persistence khá tốt. ASP.NET MVC đã xuất hiện mạnh mẽ với sự hỗ trợ cho các Công cụ Mẫu khác nhau bên cạnh ASP.NET truyền thống.

Ngay cả khi không ai đạt được sử dụng ngôn ngữ DLR để xây dựng loại khung này, bất kỳ ai có đủ sẽ có thể theo đường dẫn SpringSource và triển khai khung giống như RAILS với một số ngôn ngữ tĩnh như F #, C # hoặc VB.NET, sử dụng Aspect -Orient Container (như AspectSharp hoặc Gripper-LOOM.NET) để có được hành vi động.

Tôi rất muốn biết về bất kỳ nhóm người nào đang cố gắng phát triển khung như vậy trong .NET.


4

Tôi không biết ý của bạn là "nền tảng web phát triển nhanh". Định nghĩa về "phát triển nhanh" mà tôi quen thuộc không liên quan gì đến ngôn ngữ, mô hình hoặc khung, mà là sử dụng tạo mẫu nhanh và phát triển lặp để tạo ra một hệ thống. Bất kỳ ngôn ngữ hoặc khung có thể được sử dụng tốt như nhau.

Tôi chưa bao giờ sử dụng Grails hoặc Roo trước đây, nhưng Django và Rails đều là các khung MVC, vì vậy đối tác của chúng trong .NET sẽ là ASP.NET MVC .


1
Chà, tôi sẽ thấy ASP.NET MVC là đối tác của Spring MVC. Và để nói rằng Rails là một khung MVC giống như nói rằng Stackoverflow là một trang web QA, giống như các chuyên gia trao đổi. Đó là một tuyên bố đúng, nhưng nó bỏ lỡ tính năng quan trọng nhất và lý do cho sự thành công hoang dã của nó.
Eric Wilson

1
Hãy giải thích "tính năng quan trọng nhất". Rails không gì khác hơn là một khung MVC cho ngôn ngữ Ruby. Điều đó nắm bắt mọi thứ về nó.
Thomas Owens

2
Chà, Spring là một khung công tác MVC cho Java, nhưng nó không làm được gì nhiều khiến Rails và Grails trở nên tuyệt vời. Ví dụ, với grails, sau khi tạo một đối tượng miền, tôi có thể nhập grails generate-allvà grails tạo bộ điều khiển, khung nhìn và sẽ quản lý sự bền bỉ.
Eric Wilson

3

Bạn có thể vào Visual Studio và kéo và thả các điều khiển trên một trang web và kết nối chúng với cơ sở dữ liệu với rất ít mã. Một cú nhấp chuột để kiểm tra / xem. Và một cú nhấp chuột để tải lên một trang web (ok, nhập thông tin đăng nhập).

Không phải đây là cách làm được sử dụng nhiều nhất hoặc thậm chí được đề xuất, nhưng nó thực sự không dễ dàng hơn nhiều so với cách này.


0

Bởi vì các ứng dụng web .NET có chu trình xây dựng.

Ruby / Python là ngôn ngữ rất nhanh nhẹn / nhanh nhẹn và năng động.

Nơi tôi làm việc, chúng tôi có một ứng dụng web .NET rất lớn và thời gian biên dịch có thể so sánh với một chương trình C ++ từ trung bình đến lớn điển hình.

Trong thời gian rảnh rỗi, tôi phát triển các ứng dụng web bằng python và thời gian biên dịch là 0. Không có bước biên dịch nào cả. Trình thông dịch đang chạy chỉ tải lại các tệp .py khi bạn lưu chúng.


1
Chà, các ứng dụng Java có một chu trình xây dựng, nhưng Spring Roo vẫn hoạt động kỳ diệu cho các ứng dụng Java / Spring. Vì vậy, tôi nghĩ rằng có những vấn đề khác ở đây.
Eric Wilson
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.