Grails có đáng không? [đóng cửa]

Đây là một nửa câu hỏi, một nửa câu hỏi.

Nó có đáng để sử dụng Grails không? Tôi đang cố gắng phát triển một ứng dụng web hướng cơ sở dữ liệu tương đối đơn giản. Chuyên môn của tôi là về Java, vì vậy Grails dường như là một lựa chọn tốt. Lúc đầu, tôi nghĩ đến việc sử dụng Spring, JPA và Hibernate, nhưng tôi đã sử dụng nó trước đây và đã gặp phải tất cả các loại công việc cấu hình và mã hóa tẻ nhạt. Grails tự quảng cáo là giải quyết được vấn đề này.

Sự thất vọng lớn nhất của tôi với Grails là tất cả những thứ nhỏ nhặt không hoạt động. Ý tôi là nó không hoạt động như trực giác mà người ta nghĩ. Nó rất thô xung quanh các cạnh. Tôi gặp phải vấn đề liên tục. Đôi khi đó là sự thiếu hiểu biết của tôi về Grails - những lần khác tôi đã phát hiện ra các lỗi Grails hợp pháp.

Một vấn đề chính là thiếu tích hợp Eclipse tốt. Có một plugin Groovy và Grails, nhưng nó không làm được gì nhiều ngoài việc tô sáng cú pháp. Việc gọi Groovy từ Java và ngược lại rất khó cấu hình . Không có hỗ trợ IDE tốt là một lỗi lớn.

Điều gì xảy ra là tôi đang cố gắng phát triển ứng dụng web của mình. Vào cuối ngày, tôi nhận ra rằng tôi đã dành khoảng 85% thời gian trong ngày để gỡ lỗi các vấn đề liên quan đến Grails. Nếu đó không phải là vấn đề Eclipse thì đó là tải háo hức , tìm nạp trong chế độ xem , mối quan hệ một-nhiều , hành vi lỗi tệp trống kỳ lạ , một lỗi thuộc tính / getter kỳ lạ - nó cứ tiếp diễn. Đây chỉ là một ví dụ về các vấn đề tôi gặp phải ngày hôm nay. Buổi nói chuyện cuối cùng của tôi với Grails đã đưa ra một loạt các vấn đề khác nhau.

Đôi khi tôi tự hỏi liệu nó có đáng không. Tôi tò mò nếu những người khác đã trải qua điều này. Có những người thực sự sử dụng Grails để tạo ra một ứng dụng web một cách hiệu quả không? Có những khuôn khổ nào khác để phát triển web nhanh chóng mà tôi nên xem xét không?

Chúng tôi có một nhóm gồm 12 người, tất cả đều là những nhà phát triển Java cao cấp dày dạn đã học Grails từ 0.6B và tất cả chúng tôi vẫn đang làm việc trên các dự án dựa trên Grails. Tôi sẽ không quay lại Java một cách tự nguyện, và tất cả chúng ta đều cảm thấy nhẹ nhõm khi đã hiểu rõ về cách đi đến đâu đó nhanh chóng với ứng dụng Grails.

Đó là một cuộc đấu tranh, nó không dễ dàng và có / có sự thất vọng.

Tuy nhiên, chúng tôi đã cung cấp một cái gì đó rất nhanh chóng với những nỗ lực không ngừng của chúng tôi .. Có lỗi, nhiều cách giải quyết.

Tôi đã nghe nói về một số trường hợp các nhà phát triển giỏi Java cố gắng đi sâu vào các câu thần chú sâu sắc và phức tạp của các dự án Grails. Chúng tôi tránh tất cả Java và chuyển sang dùng pure-Grails và Groovy. Chúng tôi đảm bảo rằng chúng tôi bắt đầu đơn giản, xây dựng sự phức tạp một cách dễ dàng và thực tế nhất có thể .. Chúng tôi không dám đi sâu vào tận cùng và hy vọng rằng kiến ​​thức Java của chúng tôi đủ để mang chúng tôi.

Cuối cùng chúng tôi đã tạo ra một thứ gì đó rất lớn và phức tạp hoạt động tuyệt vời và nhanh hơn rất nhiều so với việc viết phiên bản Java / Spring / Hibernate thuần túy; và điều đó không có hỗ trợ IDE tốt và tình hình về lỗi còn tồi tệ hơn nhiều so với hiện nay.

Liên quan đến hỗ trợ Eclipse, IDE thực duy nhất để sử dụng cho Grails / Groovy là Intellij - hỗ trợ Eclipse còn rất chậm, thật đáng buồn: Tôi là một người yêu Eclipse và còn lâu mới trở thành người chuyển đổi Intellij - hỗ trợ Grails / Groovy thổi bay mọi thứ khác Tuy nhiên.

Vâng, Grails có lẽ chưa trưởng thành so với Spring. Hoặc Hibernate. Và tôi đánh cuộc rằng trong 1,5 năm đầu tiên họ tồn tại, họ đều gặp khó khăn như nhau.

Chính điều đó đã đặt ra cho bạn, hãy cẩn thận để giữ độ phức tạp ở mức tối thiểu tuyệt đối, để kiểm tra cẩn thận trước (theo ý kiến ​​của chúng tôi) và xây dựng độ phức tạp dần dần và cẩn thận.

Không có giải pháp mã nhanh nào với Java khi bạn sử dụng Spring / Hibernate trong ngăn xếp. Sự phức tạp mà Grails thể hiện là sự phản ánh sự phức tạp của riêng Spring / Hibernate. Nếu bạn cảm thấy rằng tốt hơn là bạn nên dành thời gian để làm điều đó với Java thuần túy, tôi sẽ không tranh luận ngược lại .. Tôi vẫn có WTF của mình nhưng bây giờ đường cong học tập dốc ở phía sau, tôi nghĩ tôi sẽ gắn bó với Grails thêm một số nữa.

Tôi rất thích viết ứng dụng grails vì hai lý do:

• Tôi không cần phải sử dụng Java
• Tôi có thể sử dụng Java

Tôi nghĩ rằng sau khi đã quen thuộc với grails, một người sẽ hoàn thành công việc của mình rất nhanh chóng và trang nhã.

Rất nhiều cho mặt cộng. Mặt trừ là hiệu suất, nó đánh tôi trên hai khía cạnh: triển khai và phát triển testdriven.

Tôi đã không quản lý để chạy nhiều hơn 3 ứng dụng grails trên một máy chủ duy nhất (được thuê) vì tôi nhanh chóng đạt đến giới hạn bộ nhớ và hiệu suất. Đơn giản là có quá nhiều khuôn khổ bao gồm.

Thêm vào đó, người thử nghiệm của grails không có giá trị như vậy. Khi tôi chạy các bài kiểm tra đơn vị, chúng sẽ được thực hiện ngay lập tức, không phải trong 10 đến 20 giây. Vì vậy, tôi thấy mình luôn viết logic nghiệp vụ bằng java thuần túy, vì tôi có thể kiểm tra nó nhanh hơn nhiều. Nhưng tôi đoán rằng điều này có thể được giải quyết bằng cách tích hợp tốt hơn vào IDE (nhật thực).

Tôi nghĩ rằng sự ủng hộ của Spring dành cho Grails sẽ là một động lực lớn. Nếu ai đó có thể di chuyển nó qua CRUD trên web, đó là những người đó.

Tôi cũng nghĩ rằng nó đạt đến một khối lượng quan trọng. Có một số cuốn sách mới sẽ được tung ra thị trường vào năm 2009. Tôi nghĩ rằng những cuốn sách đó sẽ giúp tỷ lệ chấp nhận.

Tôi hoàn toàn đồng ý với tình cảm ban đầu của áp phích.

Chúng tôi là một cửa hàng Java + Spring và đã có cơ hội dùng thử Grails. Đầu tiên, chúng tôi tạo ra một ứng dụng thử nghiệm rất nhỏ, nó thực hiện khá đơn giản và nó hoạt động khá tốt. Các vấn đề chính mà chúng tôi gặp phải ở đây là do chúng tôi thiếu kiến ​​thức về Groovy và Grails.

Sau thành công này (tăng cường sự tự tin), chúng tôi quyết định sẽ thử một dự án lớn hơn một chút. Đây là một kinh nghiệm đau đớn hơn nhiều. Như những người khác đã đề cập, chúng tôi đã phát hiện ra tất cả các loại lỗi và vấn đề không rõ ràng ngay trên bề mặt. Các chu kỳ khởi động lại ứng dụng trở nên cực kỳ khó khăn và trừ khi bạn có phạm vi kiểm tra thực sự tốt thì đó là cơn ác mộng để thực hiện bất kỳ loại tính toán lại.

Thực sự bực bội là gặp lỗi mã mà không có một thông báo lỗi nào! Nó chỉ không hoạt động và bạn không biết tại sao?

Tôi thích sự dễ sử dụng của các plugin cho JMS, Quartz và Remoting. Loại bỏ nhiều XML tẻ nhạt.

Tôi gần như thích GORM vì sự đơn giản của nó mặc dù chúng tôi cũng gặp một số vấn đề.

Tôi không thích tính chất được đánh máy lỏng lẻo của Groovy và thực tế là bạn phải chạy ứng dụng của mình chỉ để có thể mắc một loạt lỗi, nhắc nhở tôi quá nhiều về PHP hoặc Rails.

Vào cuối ngày, chúng tôi đang tự hỏi mình liệu có thể viết một phần mềm phức tạp có thể quản lý được bằng Grails ...

Chúng tôi có một ứng dụng Grails sắp đi vào sản xuất .... vì vậy chúng tôi sẽ xem.

Chúng tôi đang sử dụng grails + trên lớp web + java với chế độ ngủ đông và mùa xuân trên lớp dịch vụ. Đó là ba lớp cổ điển (web, logic, dữ liệu) nơi web là grails và logic được thực hiện trong java. Như thường lệ trong java, chúng tôi sử dụng các đối tượng bean đại diện cho dữ liệu giữa các lớp khác nhau.

Nó hoạt động khá tốt và đó là giải pháp tốt nhất cho trường hợp của chúng tôi vì các đối tượng bean đã có ở đó, cũng như cấu trúc cơ sở dữ liệu. Từ kinh nghiệm của chúng tôi, tôi nghĩ grails có giá trị tuyệt vời như lớp trình bày web, nhưng tôi sẽ gắn bó với java để viết các quy tắc kinh doanh và duy trì dữ liệu ứng dụng - vì grails "là" java, tất cả tích hợp grails-java đều khá thẳng tiến.

Chúng tôi sử dụng nhật thực để phát triển ứng dụng grails và nó tích hợp kém, như mọi người đã nói ở đây. Tuy nhiên, theo gợi ý từ nhà phát triển khác, chúng tôi chạy ứng dụng grails từ dòng lệnh và chỉ sử dụng eclipse để lưu các tệp nguồn và nó hoạt động khá tốt, vì ứng dụng được cập nhật nhanh chóng.

Tôi vẫn chưa cảm thấy thoải mái khi sử dụng grails ở những nơi khác ngoài lớp trình bày.

Tôi có nhiều kinh nghiệm với Ruby on Rails hơn tôi làm với bất kỳ thứ gì trong thế giới Java, vì vậy tôi sẽ đến từ một góc nhìn khác. Nhìn chung, Grails là nhiều khó khăn xung quanh-the-cạnh hơn Rails là, một phần do sự non nớt của nó, và một phần bởi vì nó dựa trên hai khuôn khổ điên cuồng phức tạp dưới-the-bìa (Spring và Hibernate). Rails cũng có một cộng đồng lớn hơn nhiều.

Nhưng Groovy với tư cách là một ngôn ngữ đã đạt được những bước tiến lớn và rất vui được làm việc cùng. Nhờ những cải tiến được thực hiện trong Groovy 1.6, Grails khá nhanh hơn một chút so với JRuby trên Rails và bạn nhận được hỗ trợ XML tốt đến kinh ngạc thông qua GPath. Có rất nhiều tính năng thú vị mà bạn nhận được khi sử dụng JVM (như đồng thời và hàng tấn mã threadsafe), nhưng không cần phải sử dụng Java (ngôn ngữ mà tôi không quan tâm lắm), vì vậy tôi thực sự có thời gian khó thuyết phục bản thân sử dụng bất kỳ thứ gì trên MRI.

Tuy nhiên, tôi phải thừa nhận rằng Python trông rất hấp dẫn.

Đối với các vấn đề về Eclipse của bạn, tôi không thể giúp gì được. Tôi sử dụng Vim và Emacs, chủ yếu là vì tôi không thể sử dụng IDE. Tuy nhiên, đối với các ngôn ngữ động như Groovy, Ruby và Python, tôi không nghĩ rằng IDE thực sự mang lại bất kỳ lợi ích thực sự nào, vì thực sự không có bất kỳ nơi nào để tạo mã hoặc nhu cầu biên dịch. Có lẽ hãy thử làm việc với IDE một thời gian và xem mọi thứ có mượt mà hơn không?

Vì vậy, vâng, tôi nghĩ Grails xứng đáng. Họ đã làm rất tốt công việc của mình trong việc khiến mọi thứ hoạt động nhanh nhất có thể, đồng thời nhóm Grails và Groovy đều thực sự, thực sự tận tâm.

Tôi hoàn toàn ở bên bạn! Grails vẫn còn cảm giác thô ráp xung quanh các cạnh đến mức gần như là một trò đùa khi so sánh nó với Rails. Nếu ít nhất thì báo cáo lỗi đã tốt hơn một chút. Nhưng tôi đoán đó có lẽ cũng là do số lượng thư viện khổng lồ mà nó sử dụng dưới vỏ bọc. Một từ: stacktrace! Tôi cũng không phải là một fan hâm mộ lớn của cách tiếp cận model-> db (Rails có db-> model). Giàn giáo cũng để lại nhiều chỗ để cải tiến. Sau đó, "không cần khởi động lại" cũng không hoạt động như quảng cáo. (Tôi không chắc điều gì tồi tệ hơn - phải khởi động lại mọi lúc hoặc đôi khi tìm thấy các hành vi kỳ lạ biến mất khi bạn khởi động lại) Và đừng giúp tôi bắt đầu với GORM. (Khi phải mất hàng giờ đồng hồ để tìm ra cách mà lẽ ra là một SQL đơn giản, bạn bắt đầu tự hỏi liệu toàn bộ ORM này có thực sự giúp bạn tiết kiệm thời gian hay không) Có thể miễn là nó đơn giản.

Ý tôi là: nó vẫn là một trong những lựa chọn tốt hơn cho một khuôn khổ khi bạn đến từ thế giới java. (Có rất nhiều thứ vô dụng ngoài kia tự gọi nó là web framework) ... nó có tiềm năng. Tôi chỉ ước nó không được xây dựng trên nhiều thứ phức tạp khác.

Dù sao - chúng ta hãy hy vọng những điều này được sắp xếp. Hiện tại, tôi đang ẩn nấp tại playframework.org , trang này cũng trông rất bắt mắt và đầy hứa hẹn.

Sẽ rất đáng giá khi họ hoàn thành plugin eclipse. Tôi nói càng sớm càng tốt. Cố gắng bán sự vui vẻ cho ông chủ của tôi sẽ không đơn giản cho đến khi điều đó xảy ra.

Tôi thấy rằng lợi thế lớn nhất của Grails là tôi không phải quan tâm đến cơ sở dữ liệu nữa - lược đồ được tạo / cập nhật tự động và việc duy trì phần lớn được thực hiện cho tôi (không phải viết truy vấn SQL nữa). Đây là một sự cứu trợ rất lớn. Một điều thú vị khác là khi bạn đã ổn định các mẫu cho bộ điều khiển và chế độ xem, việc thêm các đối tượng miền mới khá nhanh. Mặc dù tôi nghi ngờ rằng ít nhất bạn sẽ thực hiện các thay đổi liên tục cho các chế độ xem của mình, nhưng hãy điều chỉnh chúng lại với các chế độ hiện có.

Đối với IDE - có vẻ như IntelliJ là lựa chọn tốt nhất, nhưng tôi hài lòng khi sử dụng Netbeans 6.5. Tôi sử dụng MyEclipse cho tất cả các phát triển khác, nhưng Netbeans hiện đã hỗ trợ Grails tốt hơn.

Tôi là người dùng Eclipse trước khi bắt đầu sử dụng Grails. Rõ ràng là sẽ không cắt đứt được nó. Vì vậy, tôi đã thử Intellij và NetBeans. Vào thời điểm đó, Intellij đã tốt hơn so với Groovy và Grails. Tuy nhiên, NetBeans là miễn phí và điều đó đủ tốt cho tôi. Kể từ đó cả ba đều có phiên bản mới hoặc plugin mới được phát hành. Tôi vẫn đang sử dụng NetBeans vì chi phí của Intellij. Với việc mua lại G2One bởi Spring Source, một trong những kỳ vọng là hỗ trợ nhiều hơn cho Groovy và Grails trong Eclipse. Điều này sẽ cần thiết để tăng cường áp dụng.

Sử dụng Grails cho một dự án mới thật tuyệt vời. Vì vậy, phần lớn gói Enterprise Java không còn cần thiết nữa. Tôi có thể tưởng tượng việc cố gắng chuyển một cái gì đó sẽ rất khó khăn bởi vì cho đến khi bạn hiểu được điểm mạnh và điểm yếu của khung công tác thì khó có thể sử dụng nó một cách hiệu quả. Người ta hứa rằng hỗ trợ JSP sẽ trở nên dễ dàng hơn trong Grails 1.1, tôi không biết liệu sử dụng phiên bản beta trong khi cố gắng tìm kiếm một khuôn khổ mới có phải là một ý tưởng hay không. Thử nghiệm cũng đã trải qua một bản sửa đổi lớn cho phiên bản mới. Nếu thời gian cho phép, bạn có thể cân nhắc chờ đợi vì bản 1.1 sẽ sớm ra mắt.

Nếu bạn có cơ hội cho Grails thử một IDE khác khi bắt đầu một dự án từ đầu, tôi nghĩ bạn sẽ nhìn nhận nó theo một cách khác.

Tôi vừa mới bắt đầu sử dụng grails trong một dự án mới ... không cần phải viết BẤT KỲ tệp xml nào mà vẫn có sức mạnh của Spring và Hibernate thực sự tuyệt vời.

Tuy nhiên, hãy sử dụng IntellijIDEA cho IDE, tôi thực sự đã phát hiện ra Grails thông qua IDE (tôi có thể bị thiên vị, tôi ghét nhật thực).

Tổng cộng. Có rất nhiều khung công tác Java nên tiêu chuẩn này được đặt khá cao đối với những người mới và đó là một minh chứng cho Grails rằng nó có thể vượt lên trong một không gian đông đúc như vậy.

Nó vẫn có một vài cạnh sắc nét, nhưng đó chỉ là vấn đề thời gian trước khi chúng hoàn thiện, dự án cơ bản RẤT đáng giá.

Grails có thể lớn đối với loại ứng dụng của bạn (dựa trên nhiều tệp mà nó đã tạo trong lần khởi tạo đầu tiên và các tài nguyên mà nó cần). Nếu bạn đang tìm kiếm thứ gì đó đơn giản, Grails có thể không phải là thứ bạn đang tìm kiếm. Nếu bạn đang tìm kiếm một thứ gì đó đơn giản và hiệu quả, tôi nghĩ django có thể làm tốt công việc của bạn. Hãy xem cách đơn giản (cần bao nhiêu tệp) để tạo ứng dụng CRUD từ hướng dẫn của nó . Từ đây, ứng dụng của bạn có thể (tương đối) dễ mở rộng khi nhu cầu và yêu cầu của bạn ngày càng tăng.

Tôi không chắc họ sẽ có thể tạo ra Grails đúng như bạn biết. Và đúng ra, tôi muốn nói đến tất cả các chi tiết (những chi tiết nhỏ và lớn) mà cuối cùng khiến nó trở nên giòn và dễ vỡ. Tôi thậm chí không chắc rằng có một nhóm phát triển thực sự (nghĩa là hơn 2 người) đằng sau nó.

Mỗi khi tôi lặp lại một tính năng trong các dự án Grails của mình, cố gắng cải thiện một cái gì đó, thì quy trình làm việc đó giống nhau: mọi thứ đều tan rã, sau đó là hàng trăm chu kỳ kiểm tra 'google', sau đó bạn tìm ra lý do bạn không thể làm những gì bạn muốn và bạn làm điều gì đó khác.

Cuối cùng, bạn thất vọng vì thậm chí không muốn chạm vào bất cứ thứ gì đang chạy. Và những thứ không tốt, bạn bỏ chúng đi!

Tôi đang cân nhắc chuyển sang Rails qua JRuby. Đó có thể là điều tốt nhất của cả hai thế giới: một khuôn khổ web có năng lực với một cộng đồng tích cực và lớn, một nhóm các nhà phát triển chuyên dụng, một nền tảng không dựa trên các khuôn khổ phức tạp và có vấn đề như Spring hoặc Hibernate, một chu kỳ phát hành nhanh chóng và đầy tham vọng. Và JRuby bởi vì thành thật mà nói, rất nhiều tài sản Java trong ba lô của tôi, tôi không thể vứt chúng đi.

Nếu chuyên môn của bạn về Java như bạn nói. Bạn nên xem qua Play Framework - đó là một web framework lấy cảm hứng từ Ruby on Rails với chu kỳ phát triển rất ngắn - chỉ cần lưu tệp nguồn Java của bạn và cập nhật trình duyệt web của bạn. Và nếu bạn muốn thử một ngôn ngữ khác, Play Framework có một mô-đun cho phép bạn sử dụng Scala thay thế.

Tôi thích Play Framework vì nó dễ hiểu và có hiệu suất tốt. Bạn cũng có thể sử dụng JPA và Hibernate cho lớp ORM nếu muốn.