Tại sao tôi nên sử dụng Scala / Nâng trên Java / Spring? [đóng cửa]


151

Tôi biết câu hỏi này hơi mở nhưng tôi đã xem Scala / Lift như là một thay thế cho Java / Spring và tôi tự hỏi những lợi thế thực sự mà Scala / Lift mang lại là gì. Từ quan điểm và kinh nghiệm của tôi, Java Annotations and Spring thực sự giảm thiểu số lượng mã hóa mà bạn phải làm cho một ứng dụng. Scala / Lift có cải thiện điều đó không?


Câu hỏi quá cũ. Nhưng bây giờ câu hỏi sẽ là "Tại sao tôi nên sử dụng Scala / Play over XYX" và có nhiều lý do chính đáng. Tôi chuyển đến Play và không bao giờ nhìn lại.
Jus12

Câu trả lời:


113

Giả sử chúng ta thoải mái như nhau trong Scala và Java và bỏ qua sự khác biệt về ngôn ngữ (rất lớn) trừ khi chúng liên quan đến Spring hoặc Lift.

Spring và Lift gần như đối lập nhau về mặt trưởng thành và mục tiêu.

  • Mùa xuân lớn hơn khoảng năm tuổi so với thang máy
  • Nâng là nguyên khối và chỉ nhắm mục tiêu web; Spring là mô-đun và nhắm mục tiêu cả web và ứng dụng "thông thường"
  • Spring hỗ trợ rất nhiều tính năng Java EE; Nâng bỏ qua những thứ đó

Trong một câu, Spring là hạng nặng và Nâng nhẹ. Với đủ quyết tâm và nguồn lực, bạn có thể biến điều đó lên đầu, nhưng bạn sẽ cần rất nhiều cả hai.

Dưới đây là những khác biệt cụ thể mắc kẹt trong tâm trí tôi sau khi làm việc với cả hai khung. Đây không phải là một danh sách đầy đủ, dù sao tôi cũng không thể biên dịch. Điều thú vị nhất đối với tôi ...

  1. Xem triết lý

    Nâng khuyến khích đặt một số tài liệu xem trong các phương pháp hành động / đoạn trích. Mã đoạn đặc biệt sẽ được rắc các phần tử biểu mẫu được tạo theo chương trình, <div>s,<p> s, v.v.

    Điều này rất mạnh mẽ và hữu ích, đặc biệt là khi Scala có chế độ XML cấp độ ngôn ngữ dựng sẵn. Người ta có thể viết nội tuyến XML trong các phương thức Scala, bao gồm các ràng buộc biến trong các dấu ngoặc nhọn. Điều này có thể thú vị đối với các dịch vụ XML rất đơn giản hoặc các mô hình dịch vụ - bạn có thể tạo ra một bộ các hành động phản hồi HTTP tất cả trong một tệp tuyệt vời, không có mẫu hoặc cấu hình nhiều người tham dự. Nhược điểm là phức tạp. Tùy thuộc vào khoảng cách bạn đi, có một sự phân tách mờ nhạt giữa các mối quan tâm giữa chế độ xem và logic hoặc không có sự phân tách.

    Ngược lại, việc sử dụng thường xuyên Spring cho webapps tạo ra sự tách biệt mạnh mẽ giữa chế độ xem và mọi thứ khác. Tôi nghĩ rằng Spring hỗ trợ một số công cụ tạo khuôn mẫu, nhưng tôi chỉ sử dụng JSP trong bất kỳ điều gì nghiêm trọng. Thực hiện một thiết kế "fuzzy MVC" lấy cảm hứng từ thang máy với JSP sẽ là điên rồ. Đây là một điều tốt cho các dự án lớn hơn, nơi thời gian để đọc và hiểu có thể là quá nhiều.

  2. Lựa chọn Mapper quan hệ đối tượng

    ORM dựng sẵn của thang máy là "Mapper". Có một sự thay thế sắp tới được gọi là "Record", nhưng tôi nghĩ nó vẫn được coi là pre-alpha. Sách Nâng Web có các phần sử dụng cả Mapper và JPA.

    Tính năng CRUDify của thang máy , tuyệt vời như vậy, chỉ hoạt động với Mapper (chứ không phải JPA).

    Tất nhiên, Spring hỗ trợ rất nhiều công nghệ cơ sở dữ liệu tiêu chuẩn và / hoặc trưởng thành . Từ hoạt động có "hỗ trợ". Về mặt lý thuyết, bạn có thể sử dụng bất kỳ ORM Java nào với thang máy, vì bạn có thể gọi mã Java tùy ý từ Scala. Nhưng Lift chỉ thực sự hỗ trợ Mapper và (ở mức độ thấp hơn nhiều) JPA. Ngoài ra, làm việc với mã Java không cần thiết trong Scala hiện không liền mạch như người ta có thể muốn; sử dụng ORM Java, có thể bạn sẽ thấy mình sử dụng cả bộ sưu tập Java và Scala ở mọi nơi hoặc chuyển đổi tất cả các bộ sưu tập trong và ngoài các thành phần Java.

  3. Cấu hình

    Các ứng dụng nâng được cấu hình khá nhiều hoàn toàn thông qua một phương thức một lớp "Khởi động" trên toàn ứng dụng. Nói cách khác, cấu hình được thực hiện thông qua mã Scala. Điều này là hoàn hảo cho các dự án có cấu hình ngắn gọn và khi người thực hiện cấu hình thoải mái chỉnh sửa Scala.

    Spring khá linh hoạt về mặt cấu hình. Rất nhiều tùy chọn conf có thể được điều khiển thông qua cấu hình hoặc chú thích XML.

  4. Tài liệu

    Tài liệu của thang máy còn trẻ. Tài liệu của mùa xuân khá trưởng thành. Không có cuộc thi nào.

    Vì các tài liệu của Spring đã được tổ chức độc đáo và dễ tìm, tôi sẽ xem xét các tài liệu tôi tìm thấy cho thang máy. Về cơ bản có 4 nguồn tài liệu Nâng: Sách Nâng cấp , Tài liệu API , nhóm Google của LiftWeb và " Bắt đầu ". Ngoài ra còn có một bộ ví dụ mã đẹp, nhưng tôi sẽ không gọi chúng là "tài liệu" mỗi lần.

    Các tài liệu API không đầy đủ. Sách Nâng Web đã được xuất bản trên cây, nhưng nó cũng có sẵn miễn phí trên mạng. Nó thực sự hữu ích, mặc dù phong cách mô phạm quyết định của nó đôi khi làm tôi khó chịu. Đó là một chút dài về hướng dẫn và ngắn về hợp đồng. Mùa xuân có một hướng dẫn thích hợp, mà Nâng thiếu.

    Nhưng thang máy có một tập hợp các ví dụ đẹp. Nếu bạn cảm thấy thoải mái khi đọc mã Nâng và mã ví dụ (và bạn đã biết rõ về Scala), bạn có thể giải quyết mọi thứ theo thứ tự khá ngắn.

Cả hai khuôn khổ đều hấp dẫn. Có một loạt các ứng dụng mà bạn có thể chọn và làm tốt.


10
Một câu trả lời hay, một điểm tôi không đồng ý là: Mùa xuân trở nên nặng nề. Nó có một phạm vi rộng của APIS tốt và áp dụng các cách thức hoạt động cơ cấu nhất định cần thiết để đạt được kết quả tốt cho nó, nhưng so với công cụ J2EE ban đầu, nó đã thay thế nó là một giải pháp nhẹ hơn nhiều. Tất nhiên "sự nhẹ nhàng" là trong mắt của kẻ si tình, vì vậy đây chắc chắn là một lập luận chủ quan. Chỉ cần 2 xu của tôi rồi.
Brian

3
Trả lời tốt, rất khách quan. Nâng làm quá nhiều thứ có vẻ thông minh, rất ngu ngốc. Di chuyển logic trang sang phụ trợ, trộn HTML sang mã scala, tệ hơn các thẻ điều khiển bên trong mẫu trang. Tôi không biết tại sao họ làm điều này, có lẽ họ nghĩ Scala phải xử lý XML nhanh đến mức đáng kinh ngạc. "Hướng dẫn dứt khoát để nâng" là cuốn sách công nghệ tồi tệ nhất tôi từng đọc.
Sawyer

Tôi không quen thuộc với thang máy như tôi muốn. Theo ý kiến ​​của bạn, việc tạo một trình bao bọc cho đối tượng khởi động thay vì đọc các cài đặt từ tệp xml sẽ khó như thế nào? Ấn tượng đầu tiên của tôi là vì scala xử lý xml rất tốt, nên nó sẽ không quá khó khăn.
Ape-inago

Sawyer, thực tế là bạn có thể trộn HTML với mã scala không nói rằng bạn phải làm vậy. Sử dụng đoạn mã một cách thông minh sẽ phân tách mã HTML và Scala. Nhưng này, hãy tiếp tục sử dụng các thẻ kiểm soát của bạn;)
Alebon

1
@Dan, có bất kỳ cập nhật nào bây giờ rằng thang máy cũ gấp đôi so với khi bạn viết bài này lần đầu không?
Pacerier 17/2/2015

229

Tôi phải nói rằng tôi hoàn toàn không đồng ý với câu trả lời của Dan LaRocque.

Nâng không phải là nguyên khối. Nó được sáng tác trên các yếu tố rời rạc. Nó không bỏ qua các yếu tố J / EE, nó hỗ trợ các yếu tố như JNDI, JTA, JPA, v.v. Thực tế là bạn không bị buộc phải sử dụng các yếu tố này của J / EE là một dấu hiệu mạnh mẽ của thiết kế mô-đun của thang máy.

  • Triết lý quan điểm của thang máy là "hãy để nhà phát triển quyết định." Thang máy cung cấp một cơ chế tạo khuôn mẫu không cho phép bất kỳ mã logic nào trong chế độ xem, cơ chế xem dựa trên việc thực thi mã Scala và các chữ XML của Scala và cơ chế xem dựa trên Tỷ lệ . Nếu bạn chọn cơ chế tạo khuôn mẫu XML, thì bạn chọn bao nhiêu, nếu có, đánh dấu thuộc về logic kinh doanh của bạn. Sự tách biệt chế độ xem của thang máy mạnh hơn bất cứ điều gì Spring cung cấp vì bạn không thể diễn đạt bất kỳ logic kinh doanh nào trong các mẫu XML của thang máy.
  • Đối tượng của thang máy philosophy Triết lý bền bỉ là "hãy để nhà phát triển quyết định." Thang máy có Mapper là một trình ánh xạ quan hệ đối tượng kiểu ActiveRecord. Nó hoàn thành công việc cho các dự án nhỏ. Hỗ trợ thang máy JPA. Thang máy có bản tóm tắt Bản ghi hỗ trợ đưa các đối tượng vào và ra khỏi cơ sở dữ liệu quan hệ, vào và ra khỏi các cửa hàng NoQuery (Thang máy bao gồm hỗ trợ riêng cho CouchDB và MongoDB, nhưng các lớp bộ điều hợp là vài trăm dòng mã, vì vậy nếu bạn muốn Cassandra hoặc một cái gì đó khác, nó không phải là rất nhiều công việc để có được nó.) Về cơ bản, Nâng khung Web không phụ thuộc vào cách các đối tượng được cụ thể hóa thành một phiên. Hơn nữa, các chu kỳ phiên và yêu cầu được mở sao cho việc chèn các móc giao dịch vào chu kỳ yêu cầu / phản hồi là đơn giản.
  • Triết lý của thang máy là "nhóm máy chủ cần biết một ngôn ngữ, không phải nhiều ngôn ngữ." Điều này có nghĩa là cấu hình được thực hiện thông qua Scala. Điều này có nghĩa là chúng tôi đã không phải triển khai 40% cấu trúc ngôn ngữ của Java theo cú pháp XML để tạo các tùy chọn cấu hình linh hoạt. Điều đó có nghĩa là cú pháp trình biên dịch và loại kiểm tra dữ liệu cấu hình để bạn không nhận được bất kỳ phân tích cú pháp XML lạ hoặc dữ liệu không chính xác nào trong thời gian chạy. Điều đó có nghĩa là bạn không cần phải có các IDE hiểu các chi tiết của các chú thích mà bạn đang sử dụng dựa trên thư viện mà bạn đang sử dụng.
  • Đúng, tài liệu của thang máy không phải là điểm mạnh của nó.

Với những điều đã nói ở trên, hãy để tôi nói một chút về triết lý thiết kế của thang máy.

Tôi đã viết Tuyên ngôn khung web trước khi tôi bắt đầu viết thang máy. Ở một mức độ lớn, và ở một mức độ lớn hơn là đúng với bất kỳ khung web nào khác mà tôi biết, Lift đáp ứng các mục tiêu này.

Nâng ở lõi của nó tìm cách trừu tượng hóa chu trình yêu cầu / phản hồi HTTP thay vì đặt các trình bao bọc đối tượng xung quanh Yêu cầu HTTP. Ở cấp độ thực tế, điều này có nghĩa là hầu hết mọi hành động mà người dùng có thể thực hiện (gửi các phần tử biểu mẫu, thực hiện Ajax, v.v.) được thể hiện bằng GUID trong trình duyệt và chức năng trên máy chủ. Khi GUID được trình bày như một phần của yêu cầu HTTP, hàm được áp dụng (được gọi) với các tham số được cung cấp. Do GUID khó dự đoán và theo phiên cụ thể, nên các cuộc tấn công phát lại và nhiều cuộc tấn công giả mạo tham số khó khăn hơn nhiều với Lift so với hầu hết các khung web khác, bao gồm cả Spring. Điều đó cũng có nghĩa là các nhà phát triển có năng suất cao hơn vì họ đang tập trung vào hành động của người dùng và logic kinh doanh liên quan đến hành động của người dùng thay vì hệ thống đóng gói và giải nén yêu cầu HTTP.

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

Nó đơn giản mà. Vì friendRequest nằm trong phạm vi khi hàm được tạo, nên hàm đóng trên phạm vi ... không cần phải lộ khóa chính của yêu cầu kết bạn hoặc làm bất cứ điều gì khác ... chỉ cần xác định văn bản của nút (nó có thể được bản địa hóa hoặc nó có thể được kéo từ một mẫu XHTML hoặc nó có thể được kéo từ một mẫu được bản địa hóa) và chức năng để thực thi khi nhấn nút. Lift đảm nhiệm việc gán GUID, thiết lập cuộc gọi Ajax (thông qua jQuery hoặc YUI và vâng, bạn có thể thêm thư viện JavaScript yêu thích của riêng mình), thực hiện thử lại tự động với các bản sao lưu, tránh bỏ đói kết nối bằng cách xếp hàng các yêu cầu Ajax, v.v.

Vì vậy, một điểm khác biệt lớn giữa Nâng và Mùa xuân là triết lý GUID của thang máy liên quan đến chức năng có lợi ích kép là bảo mật tốt hơn nhiều và năng suất của nhà phát triển tốt hơn nhiều. GUID -> Hiệp hội chức năng đã chứng minh rất bền ... cấu trúc tương tự hoạt động cho các dạng thông thường, ajax, sao chổi, trình hướng dẫn nhiều trang, v.v.

Phần cốt lõi tiếp theo của thang máy là giữ cho mức độ trừu tượng cao xung quanh càng lâu càng tốt. Về phía tạo trang, điều đó có nghĩa là xây dựng trang dưới dạng các phần tử XHTML và giữ trang dưới dạng XHTML cho đến trước khi truyền phát phản hồi. Các lợi ích là khả năng chống lại các lỗi kịch bản trang web chéo, khả năng di chuyển các thẻ CSS đến phần đầu và các tập lệnh xuống cuối trang sau khi trang được tạo và khả năng viết lại trang dựa trên trình duyệt đích. Về phía đầu vào, URL có thể được viết lại để trích xuất các tham số (cả tham số truy vấn và đường dẫn) theo cách an toàn loại, mức độ cao, dữ liệu được kiểm tra bảo mật có sẵn để xử lý rất sớm trong chu kỳ yêu cầu. Ví dụ: đây là cách xác định phục vụ yêu cầu REST:

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

Sử dụng khớp mẫu có sẵn của Scala, chúng tôi khớp với yêu cầu đến, trích xuất phần thứ ba của đường dẫn và nhận Người dùng tương ứng với giá trị đó và thậm chí áp dụng kiểm tra kiểm soát truy cập (phiên hiện tại hoặc yêu cầu có quyền truy cập vào đã cho Hồ sơ người dùng). Vì vậy, vào thời điểm đối tượng Người dùng chạm vào logic ứng dụng, nó đã được hiệu chỉnh.

Với hai phần cốt lõi này, Lift có một lợi thế to lớn về mặt bảo mật. Để cho bạn biết về mức độ bảo mật của thang máy không ảnh hưởng đến các tính năng, Rasmus Lerdorg , người đã bảo mật cho Yahoo! có điều này để nói về FourSapes (một trong những trang web dành cho trẻ em poster):

Bốn sao đến @fiến - Trang web đầu tiên trong một thời gian tôi đã có một cái nhìn tốt về việc không có vấn đề bảo mật nào (mà tôi có thể tìm thấy) - http://twitter.com/rasmus/status/5929904263

Vào thời điểm đó, FourSapes có một kỹ sư làm việc về mã (không phải @harryh không phải là siêu thiên tài) và trọng tâm chính của anh là viết lại phiên bản FourSapes của PHP trong khi đối phó với lưu lượng truy cập tăng gấp đôi.

Phần cuối cùng của trọng tâm bảo mật của thang máy là SiteMap. Đó là một điều khiển truy cập thống nhất, điều hướng trang web và hệ thống menu. Nhà phát triển xác định các quy tắc kiểm soát truy cập cho từng trang bằng mã Scala (ví dụ If(User.loggedIn _)hoặc If(User.superUser _)) và các quy tắc kiểm soát truy cập đó được áp dụng trước khi bất kỳ kết xuất trang nào bắt đầu. Điều này rất giống với Spring Security, ngoại trừ việc nó được triển khai từ đầu dự án và các quy tắc kiểm soát truy cập được thống nhất với phần còn lại của ứng dụng, do đó bạn không cần phải có quy trình cập nhật các quy tắc bảo mật trong XML khi các URL thay đổi hoặc các phương pháp tính toán thay đổi kiểm soát truy cập.

Tóm lại, triết lý thiết kế của Lift mang đến cho bạn những lợi ích của việc kiểm soát truy cập, chống lại các lỗ hổng bảo mật hàng đầu của OWASP, hỗ trợ Ajax tốt hơn nhiều và năng suất của nhà phát triển cao hơn nhiều so với Spring.

Nhưng Nâng cũng cung cấp cho bạn sự hỗ trợ Comet tốt nhất của bất kỳ khung web nào xung quanh. Đó là lý do Novell chọn thang máy để cung cấp năng lượng cho sản phẩm Pulse của họ và đây là những gì Novell nói về thang máy:

Nâng là loại khung web cho phép bạn là nhà phát triển tập trung vào bức tranh lớn. Kiểu gõ mạnh mẽ, biểu cảm và các tính năng cấp cao hơn như hỗ trợ Comet tích hợp cho phép bạn tập trung vào đổi mới thay vì hệ thống ống nước. Xây dựng một ứng dụng web phong phú, thời gian thực như Novell Pulse đòi hỏi một khuôn khổ với sức mạnh của Nâng dưới vỏ bọc.

Vì vậy, Lift không chỉ là một khung MVC khác. Đó là một khuôn khổ có một số nguyên tắc thiết kế cốt lõi đằng sau nó đã trưởng thành rất tốt. Đó là một khung cung cấp các lợi thế kép về bảo mật và năng suất của nhà phát triển. Thang máy là một khung được xây dựng theo lớp và cung cấp cho nhà phát triển các lựa chọn phù hợp dựa trên nhu cầu của họ ... các lựa chọn để tạo chế độ xem, các lựa chọn cho sự kiên trì, v.v.

Scala và Lift cung cấp cho các nhà phát triển trải nghiệm tốt hơn nhiều so với sự kết hợp của XML, các chú thích và các thành ngữ khác tạo nên Spring.


2
Một phiên bản lưu trữ của blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html có sẵn tại replay.web.archive.org/20070220231839/http://blog.lostlake.org/.
Alan Hecht

1
Bạn đã có tôi tại bộ phận hỗ trợ riêng của MongoDB ... Tôi đang ở
Eran Medan

8
Tôi đã viết webapp từ giữa những năm 90. Tôi đã sử dụng Perl, Java, Seam, JSP và một loạt các thứ khác. Mọi người tôi biết, những người sử dụng mùa xuân đều phàn nàn về sự khó khăn trong việc cấu hình và phụ thuộc đúng, những cơn ác mộng, v.v. Tôi đã bắt đầu sử dụng thang máy trên một dự án vài tuần trước và vô cùng ngạc nhiên. Đó là khuôn khổ đầu tiên (và ngôn ngữ) tôi đã sử dụng khi mọi thứ hoạt động gần như không cần nỗ lực. Tôi đã viết hàng tá tính năng trong ứng dụng của mình cho đến nay và liên tục ngạc nhiên về việc tôi nhanh chóng hiểu đúng như thế nào ... ngay cả với những tài liệu sucky và hiểu biết hạn chế về Scala. Nhìn thấy là tin tưởng.
Tony K.

@TonyK.: Chắc chắn Spring rất nặng, nhưng nó sẽ được đền đáp nếu ứng dụng web được thay đổi rất nhiều sau đó, vì việc tái cấu trúc / mở rộng với Spring dễ dàng hơn nhiều. IMHO, nó phụ thuộc. Tôi đã sử dụng một số khung công tác khác, như Grails, cho các dự án nhỏ và tôi nghĩ nó hoàn toàn phù hợp với nó - nhưng vì điều gì đó sẽ thay đổi rất nhiều sau đó, tôi sẽ đi với Spring.
Hoàng Long

7
@ HoàngLong Có nhiều cách tiếp cận với khó khăn của sự phát triển phần mềm. Tôi chỉ đơn giản nói lên kinh nghiệm của mình: Java đang thể hiện thời đại của nó như một ngôn ngữ, cũng như các khung được xây dựng dựa trên nó. Thời gian để phát triển đến những thứ có tính biểu cảm và mạnh mẽ hơn mà không có sự điên cuồng cấu hình và nồi hơi.
Tony K.

11

Tôi khuyên bạn nên kiểm tra khung chơi, nó có một số ý tưởng rất thú vị và hỗ trợ phát triển trong Java và Scala


2
Tôi đã kiểm tra Play. Tôi đã không thấy bất cứ điều gì ngoại trừ lớp tải lại tích hợp để giới thiệu nó và với giấy phép Scala JRebel miễn phí, bạn sẽ có được điều đó với thang máy.
Tony K.

10

Chỉ để cho vui. Và vì lợi ích của việc học các phương pháp lập trình mới.


10

Tôi mạnh mẽ xem xét việc sử dụng thang máy cho một dự án web gần đây, không phải là một fan hâm mộ lớn của Spring MVC. Tôi chưa sử dụng các phiên bản mới nhất, nhưng các phiên bản trước của Spring MVC đã khiến bạn phải vượt qua rất nhiều vòng để chạy ứng dụng web. Tôi gần như đã được bán trên thang máy cho đến khi tôi thấy rằng thang máy có thể phụ thuộc rất nhiều vào phiên và sẽ yêu cầu 'phiên dính' để hoạt động chính xác. Trích từ http://exploring.liftweb.net/master/index-9.html#sec:Session-Quản lý

Cho đến khi có một công nghệ sao chép phiên tiêu chuẩn, bạn vẫn có thể phân cụm ứng dụng của mình bằng cách sử dụng phiên dính dính. Điều này mà tất cả các yêu cầu liên quan đến phiên HTTP phải được xử lý bởi cùng một nút cụm

Vì vậy, một khi Phiên là bắt buộc, người dùng sẽ phải ghim vào nút đó. Điều này tạo ra nhu cầu cân bằng tải thông minh và ảnh hưởng đến việc mở rộng quy mô, điều này ngăn cản Nâng trở thành một giải pháp trong trường hợp của tôi. Cuối cùng tôi đã chọn http://www.playframework.org/ và đã rất hài lòng. Chơi đã ổn định và đáng tin cậy cho đến nay và rất dễ dàng để làm việc với.


7

Tôi đã không đến với Nâng và Scala từ nền Java, vì vậy đây không phải là kinh nghiệm cá nhân, nhưng tôi biết rằng nhiều nhà phát triển của thang máy thấy Scala là ngôn ngữ ngắn gọn và hiệu quả hơn nhiều so với Java.


3

Mở rộng kiến ​​thức của bạn luôn là một nỗ lực đáng giá :) Tôi mới bắt đầu học Scala, nó ảnh hưởng đến cách tôi viết Java bình thường và tôi có thể nói rằng nó rất có lợi cho đến nay.


3

Tôi ghét phải hoàn toàn ném thế giới của bạn cho một vòng lặp. Nhưng bạn có thể sử dụng Scala, Java, Lift, Spring trong một ứng dụng và không có vấn đề gì.


0

Theo ý kiến ​​khiêm tốn của tôi, trí tưởng tượng là điều quan trọng.

Hãy xem xét bạn muốn viết một ứng dụng. Nếu bạn là một nhà phát triển tốt, ứng dụng sẽ được xây dựng trong tâm trí của bạn. Bước tiếp theo là khám phá cách nó hoạt động thông qua mã. Để làm được điều đó, bạn cần chuyển ứng dụng tưởng tượng thông qua chức năng dịch nó sang ứng dụng trong thế giới thực. Chức năng đó là một ngôn ngữ lập trình. Vì thế

Real app = programming language (imagined app)

Vì vậy, sự lựa chọn ngôn ngữ là quan trọng. Thế là khung. Có rất nhiều người thông minh ở đây sẽ tư vấn cho bạn về những gì nên chọn, nhưng cuối cùng, ngôn ngữ / khung dịch tốt nhất cho trí tưởng tượng của bạn nên là lựa chọn của bạn. Vì vậy, nguyên mẫu với cả hai và làm cho sự lựa chọn của bạn.

Đối với tôi, tôi đang dần học Scala và Nâng và yêu nó.


0

Nhưng vấn đề chính là chúng ta không thể so sánh mùa xuân với thang máy. Về cơ bản, thang máy được sử dụng làm khung UI và Spring được sử dụng làm khung DI.
Nếu bạn đang phát triển ứng dụng web có nhiều phần phụ trợ, chắc chắn bạn có thể sử dụng thang máy.
nhưng nếu ứng dụng web đang phát triển của bạn có một số phụ trợ hàng loạt và bạn cần phải hoàn thành mùa xuân.

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.