Service layer, Interface, perlu atau tidak?

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

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. 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. 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 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 umumnya bisa langsung buka port http, dan di proxy ke webserver (nginx).

Pada masa itu CGI cukup banyak digunakan karena mudah. Tapi bagaimana dengan aplikasi bisnis yang kompleks? Sayangnya pilihan nya terbatas antara java (termasuk bahasa baru pada saat itu),c++(lebih ribet dari java, no GC). Misalkan 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. Pada awalnya di java hanya dua application server : Kiva dan Weblogic. Kedua ini nggak akur/compatible (walaupun tidak berantem sepanas unix wars, browser wars). Kalau kita ngoding di weblogic, nggak akan bisa dijalanin di kiva 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.

Apa isi spesifikasi/standar J2EE?. Ada banyak. Pertama Webcontainer yang isinya Servlet dan JSP. Kedua adalah EJB Container yang isinya EJB untuk mengurus proses bisnis (mirip mirip layer service di spring). Servlet ini memudah kan kita sehingga tidak perlu mengurus CGI dan Webserver lagi, serta performanya lebih cepat. JSP juga, jsp isinya adalah file html namun di file html tersebut bisa kita tambahin kode java biar dinamis(mirip mirip php, 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. Selain itu ada fitur seperti clustering(menjalankan aplikasi di banyak server biar lebih kuat/cepat), 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 App 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 app server sudah jarang digunakan. Di spring kita menggunakan tomcat yang tidak sesuai standar J2EE karena hanya mengimplementasi spesifikasi WebContainer(servlet+jsp), tidak ada EJB dan lain lain sehingga lebih ringan. 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

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