2010-05-29 19 views
5

Tôi đã xem xét các khung công tác web như Rails, Grails, v.v. Tôi đã từng làm các ứng dụng trong Spring Framework với Hibernate ... và tôi muốn một cái gì đó hiệu quả hơn.Nền tảng web nào phù hợp với tôi?

Một trong những điều tôi nhận ra là trong khi một số điều trong Grails là gợi cảm, có một số vấn đề nghiêm trọng với nó. Bộ điều khiển của Grails:

1) được triển khai hết sức. Họ dường như không thể mở rộng từ các lớp siêu trong thời gian chạy. Tôi đã thử điều này để thêm các hành động cơ bản và các phương thức trợ giúp, và điều này dường như làm cho grails nổ tung.

2) dựa trên mô hình tham số yêu cầu lỗi thời (thay vì đối tượng sao lưu biểu mẫu, đẹp hơn nhiều).

3) khó kiểm tra. Các đối tượng lệnh được xử lý hoàn toàn khác nhau ... và thực sự nó khó khăn hơn để viết thử nghiệm hơn là viết mã bộ điều khiển.

4) Các đối tượng lệnh hoạt động hoàn toàn khác nhau. Chúng được xác nhận trước và bị ràng buộc, gây ra nhiều mâu thuẫn so với mô hình tham số cơ bản.

5) Các đối tượng lệnh không thể sử dụng lại được, và đó là một cơn đau ở phía sau để sử dụng lại hầu hết nội dung từ các lớp miền, như các ràng buộc và các trường. Đây là TRIVIAL để làm trong Spring cơ bản. Tại sao địa ngục lại không tầm thường để làm ở Grails?

6) Giàn giáo được tạo ra là crap thuần túy. Nó không tổng quát các chèn và cập nhật ... và nó thực sự sao chép/dán một đống mã trong hai khung nhìn: create.gsp và edit.gsp. Các quan điểm mình là đống khổng lồ của doggie do-do. Điều này được thêm phức tạp bởi thực tế là nó sử dụng các thông số cấp thấp và không phải các đối tượng.

Kiểm tra tích hợp chậm hơn 30 lần so với kiểm tra tích hợp Spring. Thật là kinh tởm.

Một số thử nghiệm giả mạo khó viết và không được đảm bảo hoạt động khi được triển khai, tôi nghĩ rằng nó không khuyến khích các chu kỳ kiểm tra nhanh, tdd.

Hầu hết mọi thứ dường như làm hỏng các grails khi nó đang chạy, như thêm taglib hoặc bất kỳ thứ gì thực sự. Vấn đề khởi động lại máy chủ không được giải quyết chút nào.

Tôi bắt đầu nghĩ rằng sẽ đi với Spring/Hibernate/Java là cách duy nhất để thực hiện. Trong khi có một chi phí khá lớn khi khởi động, tôi biết nó sẽ dần dần suôn sẻ.

Tôi không thể sử dụng ngôn ngữ như Scala ... vì thành ngữ, nó không tương thích với Hibernate.

Ứng dụng này cũng không phải là giao diện người dùng đang chạy trên cơ sở dữ liệu. Nó có một số trong đó, nhưng nó sẽ không phải là một slouch. Tôi sợ chết vì Grails bây giờ vì nó nằm trong lớp Controller.

Đề xuất về những gì tôi có thể làm?

+0

"Tôi không thể sử dụng ngôn ngữ như Scala ... vì thành ngữ, nó không tương thích với Hibernate." - thú vị, bạn sẽ xây dựng? –

+0

Về cơ bản, vì có rất nhiều phương thức spring/hibernate lấy hoặc trả về đối tượng, bạn phải thực hiện rất nhiều asInstanceOf [Bleh] trong mã của bạn. Ngoài ra còn có một sự không phù hợp giữa bộ sưu tập scala và bộ sưu tập java, vì vậy bạn cần phải thêm một số sưng lên thêm để chuyển đổi chúng. Ngoài ra còn có một hiệu suất nó. Khi sử dụng chú thích, scala cần sử dụng Array (...) xung quanh mọi tham số vì nó không có ngoại lệ một phần tử được tích hợp trong systax ... điều này làm cho một số thứ trở nên cồng kềnh hơn một chút. – egervari

+0

tại sao sử dụng instanceof? Tại sao không thêm thông tin về loại đối tượng? –

Trả lời

3

All abstractions leak. Bạn đặt tên sáu vật phẩm ở phía bên trái cho grails. Một cho mùa xuân. Có vẻ như, bạn thích mùa xuân, sau đó.

4

Bạn có thể thanh toán Play! framework. Tôi hiện đang làm việc trên một ứng dụng trong grails mà dường như đang diễn ra tốt đẹp và đã không thực sự được thực hiện nhiều với khung chơi để nó có thể hoặc có thể không làm việc cho bạn. Một trong những bổ sung gần đây cho khung chơi là mô-đun Scala cho phép bạn viết mã trong Scala.

1

Tôi bắt đầu nghĩ rằng sẽ đi với Spring/Hibernate/Java là cách duy nhất để thực hiện. Trong khi có một chi phí khá lớn khi khởi động, tôi biết nó sẽ dần dần suôn sẻ.

Sau đó, có thể xem Spring Roo (cũng đọc Grails vs Roo - why SpringSource is pushing two very similar technologies?).

+1

Vâng, nhưng ngay cả trong các cuộc biểu tình đã thất bại ... nên tôi không biết. Tôi cũng ghét nhật thực, và tôi biết tôi không cần phải sử dụng nhật thực, nhưng lần cuối cùng tôi cố gắng để Roo làm việc với IDEA, nó không phải là đi. Tôi cũng không thích jsp của nguyên liệu. Tôi đang giải trí ý tưởng thực hiện dự án trong scala vào lúc này. – egervari

1

Tôi đã sử dụng Grails trên một vài dự án trong năm qua và nhận thấy rằng năng suất phát triển vượt xa các nhược điểm và tôi không tìm thấy con mà tôi không thể làm việc.

Về một số phản đối cụ thể của bạn:

1) được thực hiện hết sức. Họ không dường như có thể mở rộng từ các lớp siêu khi chạy. Tôi đã thử điều này để thêm các hành động cơ sở và phương thức trợ giúp, và điều này có vẻ gây ra grails để thổi lên.

FWIW, tôi chưa bao giờ cảm thấy cần phải mở rộng bộ điều khiển từ lớp cơ sở. Mỗi bộ điều khiển hỗ trợ các cuộc gọi HTTP cụ thể không cho phép sử dụng lại, và bất kỳ thứ gì cần sử dụng lại có thể/nên được ủy nhiệm cho một dịch vụ.

2) được dựa trên một mô hình lỗi thời yêu cầu thông số (chứ không phải hình thức đối tượng ủng hộ, đó là nhiều đẹp hơn).

Một lần nữa, FWIW đây không phải là vấn đề đối với tôi. Grails gói tất cả các params độc đáo vào một bản đồ, đó là tất cả tôi thường cần. Nếu tôi cần nhiều hơn, tôi tạo một đối tượng Command, điều này khá đơn giản.

3) khó kiểm tra. Các đối tượng lệnh được xử lý hoàn toàn khác nhau ... và thực sự khó khăn hơn để viết kiểm tra hơn là viết mã điều khiển .

Thử nghiệm Yep trong grails là một trong những điểm thấp. Tôi đã bỏ qua việc kiểm tra Grails hoàn toàn và chỉ sử dụng Selenium để tự động kiểm tra thông qua GUI. Không lý tưởng, nhưng nó làm việc tốt cho chúng tôi.

6) Giàn giáo được tạo ra là crap thuần túy. Công cụ này không tổng hợp các chèn và cập nhật ... và thực tế là sao chép/dán một mã trong hai chế độ xem : create.gsp và edit.gsp. Hình ảnh chính là những cọc khổng lồ của việc phải làm. Đây là thêm được kết hợp bởi thực tế là nó sử dụng các thông số cấp thấp và không phải là đối tượng .

Tôi thực sự đã tìm thấy giàn giáo khá hữu ích khi bắt đầu. Nó không bao giờ làm cho nó để sản xuất ở dạng bản địa của nó (ngoại trừ đôi khi cho các ứng dụng nội bộ), nhưng nó tiết kiệm rất nhiều thời gian bắt đầu phát triển các khối xây dựng cơ bản của ứng dụng của bạn. Ngoài ra, bạn luôn có thể tạo các mẫu giàn giáo của riêng mình nếu bạn không thích các mẫu được cung cấp.

Kiểm tra tích hợp chậm hơn 302 so với kiểm tra tích hợp mùa xuân. Đó là kinh tởm.

Một số thử nghiệm chế nhạo rất khó để viết và không được bảo đảm hoạt động khi được triển khai, tôi nghĩ rằng nó không khuyến khích chu kỳ kiểm tra nhanh, tdd.

Một lần nữa, thử nghiệm có phải không phù hợp với Grails.

Hầu hết mọi thứ có vẻ như sắp xếp các mảnh đất trong khi nó đang chạy, như thêm một tag2ib hoặc bất kỳ thứ gì thực sự. Máy chủ vấn đề khởi động lại không được giải quyết chút nào.

Tôi chưa gặp bất kỳ sự cố nào trong lĩnh vực này kể từ khi 1,2 ra mắt. Đó là môi trường thay đổi trong khi chạy tốt nhất mà tôi đã làm việc cùng. Chắc chắn có một số thứ yêu cầu khởi động lại (ví dụ: mod để khởi động), nhưng đối với hầu hết các giai đoạn phát triển, nó hoạt động rất tốt.

Tôi bắt đầu suy nghĩ với Spring/Hibernate/Java là cách duy nhất để thực hiện. Trong khi có chi phí khá lớn khi khởi động, tôi biết nó sẽ cuối cùng sẽ trở nên mượt mà.

Không chỉ lúc khởi động mà còn trong suốt quá trình phát triển. Tôi đoán rằng các đội tôi đang làm việc đang sản xuất các tính năng sẵn sàng sản xuất với tốc độ 3-5x nhanh như chúng tôi có thể sử dụng các khung "truyền thống". Nó chắc chắn không dành cho tất cả mọi người và mọi dự án, và nó không hoàn hảo, nhưng nó có thể là một máy gia tốc lớn nếu bạn dự án phù hợp với thế mạnh của Grails. Thêm vào đó, bạn có thể chọn và chọn Grails bạn muốn sử dụng (so với việc gõ vào các lớp Spring/J2EE nếu bạn muốn), và tôi xem nó như là một tùy chọn "có bánh của bạn và ăn nó". 2c của tôi.

Các vấn đề liên quan