Service layer, Interface, perlu atau tidak?

Spring | Home
Sumber : https://spring.io/

Latar Belakang

(Contoh dalam kasus ini memakai Java framework spring). Namun bisa juga diteramkan di framework/bahasa lain. Umumnya pada spring terdapat beberapa layer berikut.

  1. controller/
  2. service/
  3. repository/

Namun pada beberapa kasus, terlihat overkill. Contohnya untuk fungsi CRUD data master. controller isinya satu baris saja mangil service, pas dicari declaration nya, eh ketemu interface service. Kita coba cari implementasi service nya, isinya satu baris saja manggil dao. Dan kemungkinan besar implementasi dari service dan dao nya akan hanya ada satu seumur hidup, gak akan bertambah.

Kadang kadang hal ini menjengkelkan, misal ganti method signature, ganti interface nya juga. Tujuan interface biar gonta ganti implementasi gampang, tapi seumur hidup impementasi nya hanya satu.

Solusi?

Ada 2 pendekatan. Pertama seperti tadi, controller->service->repository dengan interface di service dan repository. Kedua untuk fungsi yang simpel seperti crud data master, controller -> repository.

Jadi yang kedua untuk yang simpel simpel, business logic, validasi langsung hajar aja di controller. Ini melanggar clean architecture sih sebenernya (maafkan saya Uncle Bob πŸ˜‚ ). Selain karena business logic ditaro di controller, Validasi juga sebenernya harus dua kali. Di controller validasi untuk format datanya(error 400). Misal untuk fungsi yang sama : menambah buku baru. Controller MVC(Thymeleaf/jsp) bisa satu request sekalian nama penerbit dan kategorinya kalau penerbit dan kategorinya itu baru (belum ada sebelumnya). Sedangkan controller Restful API(misal untuk integrasi ke sistem lain), harus ada minimal 3 request = post /penerbit, post /kategori, post /buku. Dan di service layer nya, kita validasi bisnis nya (error 403) : apakah penerbit dan kategorinya ada? apakah buku dengan judul yang sama sudah ada?. Sehingga jika kita tambah controller baru lagi (misal kafka), tidak usah menulis validasi bisnis lagi, hanya format yang emang tiap controller berbeda.

Saya prefer menggunakan yang kedua, kecuali jika ada proses yang kompleks baru menggunakan pendekatan pertama. Tapi sebenernya tidak ada masalah dengan 2 pendekatan ini. Kalau dalam project ternyata pakai pendekatan pertama, saya akan pakai pendekatan peetama. Karena kedua pendektan ini sebenernya bisa di refactor dengan mudah menggunakan IDE. Apalagi bahasa static umumnya lebih mudah di refactor.

https://www.beust.com/weblog/2021/06/20/refactoring-a-dynamically-typed-language-do-it-safely-or-automatically-but-not-both/

Kesimpulan

Sumber : https://www.wiley.com/en-us/Expert+One+on+One+J2EE+Development+without+EJB-p-9780764573903

Jadi ini hanya masalah selera saja, bukan hal yang perlu di perdebatkan πŸ˜€ . Tidak seperti pada zaman J2EE/Java EE, developer merasa EJB itu overkill. Kata Rod Johnson di buku nya, 80 % fitur/teknik pada EJB sebenernya hanya untuk 20 % masalah di dunia ini. Dan kebanyakan dari kita hanya membutuhkan 20% fitur pada EJB. Sehingga lahir lah buku “Expert one to one J2EE development without EJB” yang menjadi cikal bakal lahirnya Spring Framework yang masih berjaya sampai sekarang.

Out of Topic Sedikit, Nanti Dipindahin

Para Gen Z seperti saya mungkin bingung J2EE/Java EE/EJB itu apa. Sebelum internet dan www booming pada tahun 90an, sudah ada banyak bahasa pemrograman dan aplikasi yang kompleks seperti ERP/SAP yang diakses 1 tier menggunakan mainframe+dumb terminal atau 2++ tier menggunakan server dan GUI desktop(windows/unix). Ketika WWW ditemukan (www beda dengan internet), web hanya berisi static page html yang berisi konten yang terstruktur (h1,h2,body,dll) dan hyperlink yang menyambungkan page satu ke page lain nya. Mau mengirim pesan (CRUD) lewat web/www/html? tidak bisa karena hanya static file.

Sumber : https://networkencyclopedia.com/common-gateway-interface-cgi/

Oleh karena itu dibuatlah CGI (Common gateway interface) yang menyambungkan (gateway/jembatan) www/html dengan bahasa pemrograman. Misal kita membuka abdillah.my.id/pesan?id=4, maka webserver(apache/nginx/IIS) akan menjalankan program (membuat proses baru) pesan.exe yang saya buat pakai bahasa C. Dan di pesan.exe tersebut saya bisa mendapat id pesan nya(4), setelah itu saya mengambil datanya dari database, lalu menampilkan dalam bentuk html. Html ini di proses di pesan.exe saya, dan setelah jadi output dari html nya dikirimkan lagi ke webserver. Dan webserver mengirim file html tersebut ke user. Tadi saya membuat pakai bahasa C, namun CGI sebenernya bisa pakai bahasa apa saja (python/perl/dll), bahakan bisa juga pake shell linux (bash). Karena cgi hanya akal akalan saja, sehingga performanya tidak terlalu bagus. Oleh karena itu sekarang umumnya cgi sudah tidak digunakan lagi(kecuali bahasa stateless seperti php). Untuk bahasa yang jalan terus(long running process) seperti java, go, nodejs, C bisa langsung buka port http tanpa menggunakan webserver. Walaupun umumnya kita juga tetap menggunakan webserver, namun komunikasinya menggunakan proxy (bukan CGI). Contoh kode CGI menggunakan python :

# Contoh kode CGI menggunakan python. sumber : https://en.wikipedia.org/wiki/Common_Gateway_Interface
#!/usr/bin/env python3
import cgi, cgitb
input_data = cgi.FieldStorage()
print('Content-Type: text/html') # HTML is following
print('<h1>Addition Results</h1>')
num1 = int(input_data["num1"].value)
num2 = int(input_data["num2"].value)
print('<output>{0} + {1} = {2}</output>'.format(num1, num2, num1 + num2))

Pada masa itu CGI cukup banyak digunakan karena mudah. Tapi bagaimana dengan aplikasi bisnis yang kompleks? Sayangnya pilihan bahasa terbatas. Java, bahasa baru pada saat itu terlihat menjanjinkan. C++? lebih ribet dari java, no GC. Microsoft agak telat masuk ke pasar ini(asp/j++/c#/.net). Php sekarang berbeda dengan dulu, Object oriented baru ada di Php versi 3 (1998), namepsace di php 5.3(2009). Ada perusahaan yang menambah fitur di java (anggep saja seperti membikin framework), lalu di bungkus dengan nama Application Server. sehingga programmer tidak perlu mengurus yang ribet ribet. Contoh application server pertama adalah Weblogic(Sebelum diakuisi Bea, lalu Oracle), NetDynamic/iPlanet(Sun), websphere(IBM), dll. Semua application server ini nggak akur/compatible (walaupun tidak berantem sepanas unix wars, browser wars). Kalau kita ngoding di weblogic, nggak akan bisa dijalanin di websphere dan sebaliknya. Oleh karena itu pada tahun 1999 dibuatlah standar/spesifikasi agar Application Server ini bisa kompatible. Kalau kita ngoding lalu di build/compile menjadi file WAR, file WAR nya ini bisa kita deploy di weblogic maupun di appilcation server lain tanpa mengubah kode. Nama standar/spesifikasi ini adalah J22E dan pada tahun 2005 ganti nama menjadi Java EE dan pada tahun 2019 ganti lagi jadi Jakarta EE.

Sumber : https://tekslate.com/distributed-systems-j2ee-architecture

Apa isi spesifikasi/standar J2EE?. Ada banyak. Pertama Webcontainer yang isinya Servlet dan JSP. Kedua adalah EJB Container yang isinya EJB untuk mengurus proses. Servlet ini memudah kan kita sehingga tidak perlu mengurus CGI dan Webserver lagi, serta performanya lebih cepat. Karena servlet adalah webserver. JSP juga, jsp isinya adalah file html namun di file html tersebut bisa kita tambahin kode java biar dinamis(mirip mirip php/asp, atau templating engine). Namun umumnya semua proses bisnis dan transformasi data dilakukan di luar JSP(di EJB), JSP hanya menampilkan data saja sehingga kodenya cukup singat memakai Expression Language. Dengan webcontainer(JSP) ini kita tidak perlu “print(‘<h1>’, judul_1, </h1>)” atau concat concat string untuk menjadi html seperti contoh python CGI tadi. Selain itu ada fitur seperti clustering(menjalankan aplikasi di lebih dari satu server), monitoring, connection pooling lengkap dah pokoknya. Kalau pakai CGI tadi, harus di setting lagi untuk monitoring dan clustering nya. Kalau J2EE? tinggal install app server di setiap server, sisanya semua beres diurus Application Server. Lebih mudah kan pakai J2EE?. Tapi ada juga yang bikin pusing seperti EJB. Makanya yang tadi saya bahas di spring framework(rod jonson), Komponen yang baik dari J2EE seperti webcontainer (servlet+jsp) kita tetep pake, sedangkan yang bikin pusing seperti EJB di ganti ke alternatif yang lebih mudah, yaitu spring.

Dan sekarang application server J2EE(weblogic, websphere, glassfish,jboss, dll) sudah jarang digunakan jika menggunakan Spring. Di spring kita menggunakan application server tomcat yang tidak sesuai standar J2EE karena hanya mengimplementasi spesifikasi WebContainer(servlet+jsp), tidak ada EJB dan lain lain. Bisa dibilang lebih ringan memory dan startup nya karena tidak memuat semua kompnen J2EE yang tidak dipakai di spring. Misal di spring untuk membuat restful API kita menggunakan spring mvc rest(alternatif dari JAX-RS di J2EE), maka library spring mvc rest tersebut tidak di bundle di Application Server tomcat, melainkan akan di bundle bersama war/jar aplikasi spring nya. Untuk clustering dll gimana? jaman sekarang tinggal cemplungin aja ke kubernetes/dsb yang language agnostic.

Ini spesifikasi lengkap untuk J2EE:

https://stackoverflow.com/questions/37082364/a-summary-of-all-java-ee-specifications

https://dzone.com/articles/why-its-better-to-trust-in-java-ee

Perbandingan J2EE dan Spring :

Sumber : https://www.slideshare.net/reza_rahman/java-ee-and-spring-sidebyside-34320697

Kalau anda pensaran, silahkan kotorkan tangan anda dengan dengan download, jalankan, dan bandingkan biar lebih paham :

Sun J2EE Petstore https://www.oracle.com/java/technologies/petstore-v1312.html
J2EE Without EJB Petsrore (Spring) (2004)https://www.wiley.com/en-us/Expert+One+on+One+J2EE+Development+without+EJB-p-9780764573903
Petsore Spring Jaman Now (2020)https://github.com/apache/juneau-petstore
guest
0 Comments
Inline Feedbacks
View all comments