Java Spring vs Java EE - Cuộc chiến một mất một còn
Trong cộng đồng Java, các cuộc tranh cãi về việc lựa chọn giữa Spring và JEE chưa bao giờ đi đến hồi kết. Thành phần của các cuộc tranh luận này gồm: các nhà "truyền giáo", các kiến trúc sư phần mềm, và thậm chí là cả fan cuồng của JEE và Spring.
Bạn thấy đấy, các kiến trúc sư tham gia vào tranh luận bởi họ là người chịu trách nhiệm lựa chọn nền tảng phù hợp cho dự án. Thế nhưng các developer thì sao? Họ nghĩ gì?
Tác giả là một Java developer dùng cả Spring và JEE nhưng không phải fan cuồng của bất kỳ nền tảng nào. Hôm nay, tác giả sẽ chia sẻ góc nhìn của mình về trận chiến kinh điển giữa Spring và JEE dựa trên các tiêu chí sau:
1. Quyết định của doanh nghiệp
Trong nhiều tổ chức, việc lựa chọn công nghệ không hoàn toàn dựa trên ý kiến của Developer. Nhất là trong các công ty lớn, thường sẽ có một Architect team - tập hợp các kiến trúc sư phần mềm - họ sẽ là người chọn lựa các nền tảng, ngôn ngữ, framework và thư việc cho các dự án.
Bên cạnh đề xuất của Architect team, trong quá trình chọn lựa công nghệ, các doanh nghiệp lớn cũng xét tới các yếu tố sau:
- Sự trưởng thành của nền tảng/ngôn ngữ/framework/thư viện
- Hỗ trợ về mặt thương mại
- Phí bản quyền
......
Đấy là còn chưa nhắc đến các yếu tố "chính trị".
Một developer có vẻ hơi thấp cổ bé họng khi chen chân vào quá trình quyết định những vấn đề kia. Do đó, không cần quá lo lắng về khía cạnh này.
2. Chuyển đổi công nghệ
Nếu bạn làm tốt Spring hoặc JEE, việc chuyển đổi qua công nghệ còn lại cũng không có gì khó khăn.
Tôi rất ngạc nhiên nếu có người nghĩ tôi là một chuyên gia JEE và mù tịt về Spring...
Cả Java EE và Spring đều làm việc trên core API giống nhau (servlet,JPA, JMS, Bean Validation ...), chúng chỉ khác nhau về cơ chế liên kết các thành phần.
Mặc dù vẫn tồn tại những API khác nhau cho những thứ như Dependency Injection (Spring DI, CDI), REST(JAX-RS,Spring MVC).... tuy nhiên chúng làm việc gần giống nhau.
Và sẽ có những ý kiến khẳng định rằng CDI type safe hơn Spring DI... Chẳng phải rằng CDI và Spring DI đều hoạt động như nhau khi xảy ra một trong các trường hợp...
- Quá trình Injection sử dụng @Autowire hoặc @Inject đều diễn ra tốt đẹp nếu chỉ có một Spring bean hoặc CDI bean.
- Injection thất bại nếu có nhiều hơn một Spring bean hoặc CDI bean được implement... Một lỗi sẽ được bắn ra: "Found more than one eligible beans that can be inject"
- Sử dụng @Produces hoặc @Bean để biến các custom object thành bean provider.
Cho đến nay, tôi chưa hề thấy một chuyên gia Spring không thể sử dụng được JEE và ngược lại....
3. Spring vs JEE vs sự thân thiện...
Có lẽ ở thời điểm hiện tại, mọi người đều hiểu được rằng thành công của một công nghệ không chỉ đơn thuần phụ thuộc vào khả năng của công nghệ đó, nó còn phụ thuộc vào việc đón nhận công nghệ đó từ các developer.
Điều quan trọng nhất: không phải developer nào cũng là ngôi sao. Số lượng developer "trung đẳng", tức là "nhìn lên chả thấy mình bằng ai, nhìn xuống cũng không thấy ai bằng mình" chiếm tỉ lệ áp đảo trong ngành. Vì thế một framework dễ dàng trở nên phổ biến nếu nó được đón nhận nhiệt tình từ phía các developer "trung đẳng" này.
Spring rất khá trong khoản này bới nó mang đến rất nhiều công cụ hữu ích đơn giản nhưng không kém phần mạnh mẽ: Spring Boot, Spring Security, Spring Integration, Spring Social,... Bên cạnh đó, hệ thống templates của Spring thường gãi đúng chỗ ngứa của các developer "trung đẳng" trong việc giảm thiểu sự dài dòng cho quá trình coding.
Java EE cũng không chịu kém cạnh với JBossForge, Wildfly Swarm, v.v... để giúp các developer có một khởi đầu suôn sẻ. Một vài framework xây dựng trên JEE như Picketlink đã được xem xét nhưng thật ra nó phức tạp một cách không cần thiết.
Tôi chỉ cố gắng nhắn nhủ với các bạn rằng, Java EE và Spring đều có thể giúp bạn làm được rất nhiều thứ. Điều quan trọng làm nên sự khác biệt là công nghệ nào khiến các developer "sướng" hơn - công nghệ đó sẽ được tung hô.
4. Tranh cãi trong ngõ cụt
Tôi thấy rất rất nhiều các cuộc tranh luận giữa 2 nhóm ủng hộ JEE và Spring đang tập trung vào những vấn đề đã lỗi thời, đại loại như:
Spring nặng về XML
Chỉ trích này, không đâu khác, đến từ "cộng đồng hâm mộ" JEE. Thế nhưng tôi cá là họ đang chạy Spring 2.5, ra đời cách đây gần chục năm... Haiza, các bạn thân mến, hãy đến spring.io và cảm nhận sự khác biệt... Hiện tại là 2016 và Spring 4.4.2 hỗ trợ config bằng cả file Java lẫn XML.
"EJB rất tồi!" ........."JSF thậm chí còn tệ hơn!"
Các bạn của tôi, hãy chú tâm vào việc cập nhật công nghệ! Đừng đánh giá EJB 3.x với các kinh nghiệm từ thời EJB 2.x 7 năm về trước.
Ràng buộc với nhà cung cấp
Việc lựa chọn một nền tảng không bị giới hạn khả năng kết hợp bởi một nhà cung cấp cố định sẽ giúp ích cho bạn. Tuy nhiên việc lựa chọn một nền tảng chỉ phụ thuộc vào tính ràng buộc của nó với nhà cung cấp lại là một lựa chọn tồi. Tiêu chí này chỉ là thứ yếu trong việc lựa chọn các nền tảng công nghệ.
Không cần thư viện ngoài...
"Chúng tôi thừa khả năng để xây dựng một thư viện logging"
"Tôi sẽ tự viết HTTP Client của mình, quá đơn giản!"
"Tôi sẽ tự phát triển các thư viện tiện ích...:"
Tôi thấy những ý kiến như trên chả khác gì đi phát minh lại bánh xe, rất tốn kém và lãng phí thời gian cũng như công sức con người.
5. "Các chú non lắm , theo cái framework X này làm gì cho nhọc, dùng cái Y như anh, vừa nhanh vừa tiện."
Công thức này tôi thấy ở khá nhiều các topic tranh luận, đặc biệt là trên Reddit. Bạn cứ thử post một cái gì đó liên quan tới "cuộc chiến: của JEE với Spring mà xem, 10 phút sau, sẽ có 2 nhóm "choảng nhau" trong topic của bạn chỉ vì một nhóm không sử dụng công nghệ ưa thích của nhóm còn lại...
Chúng ta là lập trình viên, chúng ta dành hàng giờ để nghĩ một thuật toán, thế tại sao lại không dành ra vài phút để xem xét vấn đề một cách trọn vẹn? Nếu Java EE là nền tảng dở ẹc, tại sao nhiều người vẫn chọn nó thay vì Spring... Nếu Spring không tốt, tại sao vẫn có nhiều dev yêu nó ? Hãy tôn trọng ý kiến và hoàn cảnh của từng người. Chúng ta không ai giống ai cả. Bên cạnh việc này, bạn cũng nên tìm hiểu lý do mà họ chuyển từ nền tảng này sang nền tảng kia vì ít nhiều nó cũng giúp ích cho các quyết định của bạn sau này.
Rồi bạn sẽ sớm nhận ra, đằng sau cuộc chiến thực sự giữa 2 công nghệ này, developer chúng ta mới là người hưởng lợi.
Via Techmaster
