Penerapan Object Relational Mapping pada

6
HASIL DAN PEMBAHASAN
Analisis Permasalahan Ketidaksesuaian
Untuk mendapatkan gambaran yang
lebih lengkap terhadap Ritel ERP (Ernita,
2008) yang akan dianalis, berikut ini
diuraikan deskripsi umum ERP untuk
perusahan Ritel tersebut.
1 Deskripsi Umum Aplikasi Ritel ERP
Sistem ERP Ritel yang dikembangkan
Ernita (2008) terdiri atas tiga mudul, antara
lain:
Modul pembelian (Business to Business)
 Purchase Requisition (PR) yang dikirim
oleh kepala gudang kepada pihak
pengadaan barang.
 Request for Quotation (RFQ) dan
Purchase Order (PO) yang dikirim oleh
bagian pengadaan kepada supplier.
 Demand Order (DO) yang dikirim oleh
supplier kepada bagian pengadaan
barang.
 Goods Receive yang diperiksa oleh
kepala gudang saat barang diterima.
 Manajemen Inventory.
 Daftar supplier.
Modul Penjualan (Business-to-Customer)
 Daftar katalog yang ditampilkan kepada
pelanggan.
 Submodul pemesanan (add to cart)
 Konfirmasi tagihan dan pembayaran.
 Pengantaran barang.
 Daftar pelanggan.
Modul akuntansi
 Jurnal buku besar (General Ledger)
 Konfirmasi tagihan dan pembayaran.
 Account Receivable (AR)
 Account Payable (AP)
 Manajemen kode akun.
Masing-masing modul pembangun Ritel
ERP tergabung pada satu basis data yang
terpusat.
2 Analisis Masalah Ketidaksesuaian
Aplikasi Ritel ERP membutuhkan basis
data dalam menjalankan proses bisnisnya.
Tiga modul utama pembangun aplikasi Ritel
ERP mengakses pada satu basis data yang
terpusat. Setiap modul mempunyai tabel
master untuk inisialisasi data dari
lingkungan proses bisnis aplikasi Ritel ERP
dan tabel transaksi sebagai hasil transaksi
saat menjalankan proses bisnisnya. Tabel
master dan tabel transaksi yang dirancang
untuk membangun aplikasi Ritel ERP dapat
dilihat pada Lampiran 1.
Pada penelitian ini, aplikasi Ritel ERP
dikembangkan
dengan
pendekatan
berorientasi objek menggunakan bahasa
pemrograman Java, sedangkan sistem
manajemen basis data yang digunakan
adalah basis data relasional. Oleh karena itu,
terdapat ketidaksesuaian (mismatch) yang
ditimbulkan pada perbedaan konsep
tersebut. Pada penelitian ini, tidak semua
aspek ketidaksesuaian ditemukan. Aspek
ketidaksesuaian yang muncul adalah aspek
granularity, identitas, asosiasi antarentitas,
dan navigasi data.
Uraian berikut memaparkan analisis
ketidaksesuaian pada aspek:
a Granularity
Ketidaksesuaian pada aspek granularity
terjadi karena pada basis data relasional
tidak mengenal user-defined-data-type atau
tipe data yang didefinisikan oleh pengguna.
Ketidaksesuaian aspek granularity yang
ditemukan pada penelitian ini terjadi saat
mendefinisikan properti address pada
entitas Supplier. atribut Address terdiri
atas street, town, state, zip_code.
Aribut address akan dipisahkan menjadi
class berbeda saat pembuatan DTO, akan
tetapi setelah dipetakan tetap masuk sebagai
proserti tabel PU_SUPPLIER.
b Identitas
Ketidaksesuaian pada aspek identitas
terkait dengan perbedaan pengenal identitas
objek dan tabel. Pada objek identitas
dibedakan menjadi nilai dan alamat
memorinya. Oleh karena itu, terdapat dua
notasi yang melambangkan kesamaan suatu
identitas, yaitu lambang sama dengan (==)
dan method equals(). Sebagai contoh
(a == b), berarti variabel a dan b
memegang alamat reference yang sama pada
memori, sedangkan (a.equals(b)),
secara lojik mempunyai nilai yang sama.
Pada basis data relasional, identitas dari
suatu tabel disebut dengan primary key.
Dengan demikian, sering kali terjadi objek
yang secara lojik sama (a.equals(b))
dan mewakili satu baris dalam tabel basis
data, tetapi objek tersebut tidak berada pada
satu lokasi alamat memori yang sama.
7
c Asosiasi
1 Melakukan Konfigurasi Basis Data
Kebanyakan entitas pada basis data
mempunyai keterhubungan dengan entitas
yang lainnya. Elemen yang menghubungkan
kedua tabel tersebut ditandai dengan foreign
key.
Tahap konfigurasi merupakan tahap awal
sebelum melakukan akses terhadap basis
data. Konfigurasi basis data disimpan pada
file jdbc.properties. Isi dari file
jdbc.properties adalah sebagai berikut:
Elemen penghubung dua objek ditandai
dengan
sebuah
reference
object.
Permasalahannya adalah reference object
bergantung pada arah dari asosiasinya
(direction of relationship). Apabila asosiasi
antara dua objek terjadi pada dua arah, maka
harus didefinisikan dua kali pada setiap
classnya. Akan tetapi foreign key pada tabel
relasional tidak mengenal arah dari
asosiasinya, karena asosiasi antara dua tabel
dihubungkan dengan tabel join.
1
2
3
4
5
6
7
8
9
10
Ketidaksesuaian pada aspek asosiasi
meliputi relasi one-to-one, one-to-many, dan
many-to-many. Masing-masing asosiasi
antarentitas bisa dilihat pada class diagram
dan ER diagram pada Lampiran 2 dan
Lampiran 3.
d Navigasi data
Ketidaksesuaian pada aspek navigasi
terkait
dengan
masalah
bagaimana
mengakses suatu objek yang berasal dari
objek lain. Menurut arahnya, navigasi data
terbagi menjadi dua macam, yaitu:
unidirectional dan bidirectional. Pada
konsep pemrograman berorientasi objek
konsep arah navigas menentukan suatu
objek dapat diakses melalui objek lain,
sedangkan pada basis data relasional konsep
arah navigasi tidak mempengaruhi proses
pengaksesan data dari tabel lain.
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek
lain bisa langsung menggunakan method
getter. Lain halnya dengan basis data
relasional,
properti
yang
menjadi
penghubung antara dua tabel yang berelasi
yaitu foreign key.
Perancangan dan Implementasi ORM
dan Design Pattern
Setelah
ditemukan
empat
aspek
ketidaksesuaian tersebut diimplementasikan
ORM. Selain itu juga diterapkan design
pattern
untuk
menghilangkan
ketidaksesuaian yang muncul pada tahap
analisis tersebut, meliputi:
jdbc.username=root
jdbc.password=admin
jdbc.url=jdbc:mysql://localhost:
3306/erp
jdbc.driver=com.mysql.jdbc.Driver
hibernate.dialect=org.hibernate.
dialect.MySQL5InnoDBDialect
hibernate.show_sql=true
hibernate.hbm2ddl.auto=create
hibernate.format_sql=true
Baris pertama sampai ke lima merupakan
properti konfigurasi koneksi basis data yang
berisi username, password, host dan port
basis data, dan library koneksi yang
digunakan.
Kode pada baris ke enam menentukan
jenis dialek SQL yang akan dipetakan. Baris
ke delapan adalah properti untuk
menampilkan hasil query yang telah diubah
ke dalam bentuk SQL. Baris ke sembilan
merupakan
properti
yang
berfungsi
mengotomasi pembuatan basis data dari
awal sampai akhir. Dan baris ke sepuluh
untuk menghasilkan query dengan format
SQL.
2 Membuat Class DTO (Data Transfer
Object)
DTO
merupakan
class
yang
merepresentasikan setiap tabel pada basis
data. DTO dibuat berdasarkan UML class
diagram yang telah dirancang. DTO berisi
class JavaBean yang setiap propertinya akan
merepresentasikan atribut-atribut pada tabel.
Skema
proses
pembuatan
DTO
diilustrasikan pada Gambar 4.
8
Product
-id : int
-prodName : string
-unitPrice : double
public class
private
private
private
//getter and
}
Product{
int id;
String prodName;
Double unitPrice;
setter method
product
PK
id : int
prod_name : varchar
unit_price : longint
Prod_ID
Prod_name
Unit
price
1
pupuk
100
2
bibit
200
Gambar 4 Skema Pembuatan DTO.
Ketidaksesuaian yang muncul pada tahap
analisis diatasi oleh ORM pada saat
merepresentasikan class DTO dan diakses
sebagai objek.
Uraian
berikut
menjelaskan
implementasi konsep ORM untuk mengatasi
ketidaksesuaian pada aspek granularity,
identitas, asosiasi, dan navigasi data.
a Aspek Granularity
Proses pemetaan untuk memecah entitas
menjadi entitas yang lebih kompleks pada
atribut address dalam entitas Supplier
menjadi satu entitas address ditulis sebagai
berikut:
- Class Supplier
1
2
3
4
5
6
7
@Entity
@Table(name = "PU_SUPLIER")
public class Supplier{
@Embedded
private Address address = new
Address();
}
-
Class Address
1
2
3
4
5
6
@Embeddable
public class Address {
private String street;
private String city;
private String zipCode;
}
Properti @Embeddable pada baris
pertama class Address mengindikasikan
bahwa class Address merupakan entitas
yang bisa dilekatkan atau dimasukan ke
dalam entitas lain. Properti @Embedded di
baris ke lima pada class Supplier
menandakan bahwa entitas Address
melekat pada entitas Supplier.
b Aspek Identitas
ORM mengatasi ketidaksesuaian pada
aspek identitas dengan menambah properti
identity pada setiap entitas atau class DTO
seperti pada potongan program berikut:
1
2
3
4
5
6
7
8
9
@Entity
@Table(name = "IN_ITEM")
public class Item{
@Id
@GeneratedValue(strategy=
GenerationType.AUTO)
@Column(name="id")
private Long id;
}
Kode pada baris pertama dan kedua
menandakan bahwa class tersebut mewakili
sebuah entitas pada basis data dengan nama
tabel IN_ITEM.
@Id pada baris ke empat merupakan
properti yang merepresentasikan primary
key, secara lojik properti @Id pada class a
berbeda dengan @Id pada class b. Dengan
demikian pengujian apakah isi class a sama
dengan class b bisa ditulis seperti berikut:
a.getid().equals(b.getId()).
Properti @GeneratedValue (strategy
=
GenerationType.AUTO
merupakan
pengisian id yang secara otomasi seperti
auto_increment pada tabel relasional.
c Aspek Asosiasi
Asosiasi antara dua entitas terdiri atas
one-to-one, one-to-many, dan many-tomany. Proses pemetaan asosiasi antara dua
entitas adalah sebagai berikut:
 One-to-one
Gambar 5 Pemetaan Asosiasi one-to-one.
9
Gambar 5 merupakan ilustrasi dari class
 One-to-many
Demand yang berasosiasi one-to-one dengan
class Order. Letak foreign key atau join
column ditambahkan pada entitas yang
mempunyai total participation pada asosiasi
yang menghubungkannya.
Pada entitas yang mempunyai asosiasi
dua
arah
(bidirectional)
diperlukan
penambahan properti mappedBy oleh
entitas yang tidak total participation (entitas
partial participation), sedangkan pada
entitas yang mempunyai asosiasi satu arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan dua class Demand dan
class Order merupakan contoh asosiasi dua
arah (association bidirectional) dan class
Demand bersifat
total participation.
Pemetaan class Demand dan class Order
dapat dituliskan sebagai berikut:
-
Class Order
1
2
3
4
5
6
@Entity
@Table(name="pu_order")
public class Order {
@OneToOne (mappedBy="order")
private Demand demand;
}
-
Class Demand
1
2
3
4
5
6
7
@Entity
@Table(name="pu_demand")
public class Demand {
@OneToOne
@JoinColumn (name="id_order")
private Order order;
}
Properti Join Column dimasukan pada
class Demand karena entitas Demand
mempunyai total participation. Dengan
demikian, objek Demand menentukan
asosiasi antara dua entitas tersebut.
Asosiasi one-to-one di atas disebut
biderectional karena masing-masing class
memerlukan
reference
yang
menghubungkannya. Baris empat dan baris
enam pada class Demand menandakan suatu
reference yang mewakili foreign key dari
entitas Order. Begitu pula pada class
Order, reference yang menghubungkannya
ditulis dengan mappedBy yang dituliskan
pada baris ke empat dan lima. Properti
mappedBy=”order” pada class Order
merujuk pada nama atribut order pada
class Demand.
Gambar 6 Pemetaan Asosiasi one-to-many.
Gambar 6 merupakan ilustrasi class
yang berasosiasi one-tomany dengan class RequisitionDetail.
Jadi setiap satu objek Requisition terdiri
atas banyak objek RequisitionDetail.
Requisition
Seperti halnya asosiasi one-to-one,
asosiasi one-to-many mempunyai join
column yang disimpan pada entitas yang
mempunyai total participation. Akan tetapi
pada asosiasi one-to-many, entitas yang
mempunyai total participation pasti berada
pada entitas yang berkardinalitas many.
Dengan demikian, dapat dikatakan join
column berada pada entitas dengan
kardinalitas many.
Class Requisition berasosiasi one-tomany dengan class RequisitionDetail.
Apabila asosiasinya bidirectional, maka
dapat
dikatakan
class
RequisitionDetail berasosiasi many-toone dengan class Requisition. Proses
pemetaannya ditulis sebagai berikut:
- Class RequisitionDetail
1
2
3
4
5
6
7
@Entity
@Table (name="pu_req_detail")
Public class RequisitionDetail {
@ManyToOne
@JoinColumn (name="id_req")
private Requisition requisition;
}
-
Class Requisition
1
2
3
4
5
6
7
8
9
@Entity
@Table(name="pu_req")
public class Requisition{
@OneToMany(mappedBy =
"requisition")
private List <RequisitionDetail>
reqDetail = new ArrayList
<RequisitionDetail> ();
}
Asosiasi many-to-one di atas bersifat
biderectional, sehingga properti join
10
column
berada pada entitas yang
berkardinalitas
many
yaitu
class
RequisitionDetail. Akan tetapi pada
entitas
yang
berkardinalitas
one
ditambahkan properti mappedBy sebagai
reference.
Properti asosiasi dan reference dalam
class RequisitionDetail ditulis pada
baris empat dan baris lima. Pada class
PurchaseRequisition, reference yang
menghubungkannya
ditulis
dengan
mappedBy seperti pada baris empat sampai
baris delepan.
Apabila
asosiasinya
unidirectional,
properti
mappedBy
pada
class
Requisition
dihilangkan.
Properti
mappedBy = “requisition” merujuk
kepada atribut “requisition” pada class
RequisitionDetail.
 Many to many
-
Class Group
1
2
3
4
5
6
7
8
9
@Entity
@Table(name = "ad_group")
public class Group {
@ManyToMany(mappedBy=
"groups")
private List <Modul>
moduls = new ArrayList
<Modul>();
}
- Class Modul
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Entity
@Table(name="ad_modul")
public class Modul {
@ManyToMany
@JoinTable (name =
"ad_modul_group",
joinColumns={
@JoinColumn(name=
"id_ad_modul")},
inverseJoinColumns={
@JoinColumn(name=
"id_ad_group")})
private List <Group> groups =
new ArrayList < Group>();
}
Peoperti Join table dimasukan pada
properti yang mempunyai total participation
yaitu class Modul. Objek Modul
menentukan asosiasi pada kedua entitas
tersebut.
Gambar 7 Pemetaan Asosiasi many-to-many.
Gambar 7 merupakan ilusrasi class
Group berasosiasi many-to-many dengan
class Modul. Kedua entitas yang berasosiasi
many-to-many dihubungkan oleh reference
berupa join tabel. Join tabel memiliki
dua buah atribut foreign key yang berasal
dari masing-masing entitas.
Atribut join tabel dimasukan pada
entitas yang memilki total participation
pada asosiasi tersebut. Properti mappedBy
ditambahkan
kepada
entitas
partial
participation apabila asosiasinya dua arah
(bidirectional), sedangkan pada entitas yang
mempunyai
asosiasi
satu
arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan asosiasi di atas
merupakan asosiasi dua arah (association
bidirectional) dan entitas Modul mempunyai
total participation. Pemetaan class Group
dan class Modul dituliskan seperti berikut:
Asosiasi many-to-many di atas bersifat
biderectional karena masing-masing class
memerlukan
reference
yang
menghubungkannya. Properti many-to-many
pada class Modul ditulis pada baris empat.
Kemudian
reference
yang
menghubungkannya berupa join table
yang terdiri atas identity dari masing-masing
entitas. Properti join table ditulis pada
baris lima sampai empat belas dalam class
Modul. Dalam class Group, reference yang
menghubungkannya ditulis pada baris empat
sampai
baris
delapan.
Properti
mappedBy=”groups” pada class Group
merujuk pada nama atribut groups pada
class Modul.
Hasil pemetaan dari asosiasi many-tomany antara dua class tersebut adalah dua
tabel hasil transformasi dari objek yaitu
AD_MODUL dan AD_GROUP kemudian satu
tabel asosiasi AD_MODUL_GROUP.
d Aspek Navigasi data
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek
11
lain bisa langsung menggunakan method
getter. Contoh:
- Class Item
1
2
3
4
5
6
7
@Entity
@Table(name = "IN_ITEM")
public class Item {
@ManyToOne
@JoinColumn(name="id_brand")
private Brand brand;
}
Class Item mempunyai variabel brand
dengan tipe data Brand seperti ditulis pada
baris ke enam. Untuk mengakses nilai
brand dengan tipe data Brand pada class
Item menggunakan method getter seperti
berikut:
invItem.getInvProdBrand.getName();
Apabila arah navigasinya unidirectional,
maka tidak terdapat properti entitas Item
pada class Brand, sehingga class Brand
tidak bisa mengakses properti entitas Item.
Tetapi
apabila
arah
navigasinya
bidirectional, maka pada class Brand
terdapat properti entitas Item seperti
berikut:
-
Class Brand
1
2
3
4
5
6
@Entity
public class Brand {
@OneToMany(mappedBy="brand")
private List <Item> item = new
ArrayList<Item>();
}
Properti mappedBy pada baris ke tiga
menandakan
bahwa
class
tersebut
mempunyai asosiasi bidirectional. Untuk
mengakses variabel item dengan tipe data
Item
dari class Brand menggunakan
method getter seperti berikut:
invProdBrand.getInItem.getName();
Basis data relasional tidak mengenal
konsep arah navigasi dalam mengakses data.
Properti yang menjadi penghubung antara
dua tabel yang berelasi yatiu foreign key.
Tabel ITEM dan BRAND mempunyai relasi
one-to-many kemudian foreign key berada
pada tabel ITEM. Selama ada foreign key
yang menghubungkan kedua tabel, proses
query yang melibatkan kedua tabel bisa
dijalankan.
Query berikut merupakan query untuk
mengakses
properti
item
dengan
berdasarkan id_brand pada tabel ITEM.
Select * from IN_ITEM i left
outer join IN_PROD_BRAND pb on
i.id=pb.id where i.id=123
Properti left outer join menandakan
bahwa foreign key berada pada tabel ITEM.
3 Membuat Fungsi Akses Data
Pada penelitian ini, DAO pattern
digunakan untuk proses enkapsulasi fungsi
untuk mengakses data ke dalam lapisan yang
berbeda, sehingga aplikasi tidak perlu
mengetahui detail proses suatu data diakses.
DAO berisi method (fungsi) untuk
mengakses dan memanipulasi data. Pada
penerapannya,
DAO
dapat
diimplementasikan dengan native query atau
bahasa query basis data relasional (Structure
Query language). DAO juga dapat
diimplementasikan dengan konsep ORM
dengan menggunakan HQL (Hibernate
Query Language).
Proses pembuatan fungsi-fungsi akses
dan manipulasi data memanfaatkan konsep
design pattern, yaitu factory method dan
singleton. Sebelum melakukan akses dan
manipulasi data, terlebih dulu dibuat objek
dataSource yang berisi referensi dari
properti koneksi basis data. DataSource
memanggil referensi properti koneksi basis
data yang ada pada file konfigurasi
jdbc.properties, antara lain: username,
password, server dan port, nama url basis
data, dan jenis driver RDBMS. Objek
dataSource dan semua objek DAO hanya
diinstansiasi satu kali selama aplikasi
berjalan. Objek dataSource dimasukan ke
setiap DAO ketika DAO diinstansiasi,
sehingga proses koneksi basis data tidak
dilakukan secara berulang-ulang melainkan
cukup dipanggil apabila diperlukan.
Framework ORM yang digunakan untuk
proses pengaksesan data pada penelitian ini
adalah Hibernate. DAO diimplementasikan
menggunakan HQL (Hibernate Query
Language). DAO berisi method untuk
mengakses dan memanipulasi data seperti
create, update, delete, insert, select, dan
join.
Pada penelitian ini, proses pembuatan
objek dataSource dan proses memasukan
dataSource ke dalam semua DAO
dilakukan menggunakan Spring Framework
dengan teknik Inversion of Control (IoC).
Teknik IoC dalam pembuatan objek
12
dataSource dapat dilihat pada Lampiran
5.
Selain objek dataSource, objek yang
diperlukan
untuk
mengakses
data
menggunakan
ORM
adalah
objek
sessionFactory. Seperti halnya objek
dataSource, objek sessionFactory
bersifat singleton, jadi objeknya hanya
dibuat sekali sepanjang aplikasi berjalan.
Objek sessionFactory dipanggil oleh
setiap class DAO yang mengakses basis
data.
membuat
objek
SessionFactory
session yang diperlukan untuk proses
transaksi yang berlangsung saat mengakses
data. Session merupakan objek yang
hanya sekali pakai, digunakan untuk
melakukan transaksi basis data dan setelah
selesai transaksi, session langsung ditutup.
Siklus hidup objek session berbeda
dengan
objek
sessionFactory,
sessionFactory dibuat sekali sepanjang
aplikasi berjalan, sedangkan session
dibuat selama proses suatu
transaksi
berlangsung. Session bertanggungjawab
selama proses transaksi, session tidak
bisa ditutup sebelum transaksi berhasil dan
session akan melakukan rollback apabila
transaksi gagal.
Pada penelitian ini, proses pembuatan
sessionFactory dan proses memasukan
objek sessionFactory ke dalam semua
DAO dilakukan menggunakan Spring
framework dengan teknik Inversion of
Control (IoC) seperti halnya pada
pembuatan dan penggunaan dataSource.
Teknik IoC untuk sessionFactory dapat
dilihat pada Lampiran 5.
session dibuat oleh class
HibernateDaoSupport melalui method
getHibernateTemplate.
Method
getHibernateTemplate
bertujuan
Objek
membersihkan lapisan aplikasi dari kode
pengaksesan data yang berulang-ulang.
Method
getHibernateTemplate
membuat kode program untuk penyimpanan
objek ke dalam basis data menjadi sebagai
berikut:
public class CartDaoHibernate extends
HibernateDaoSupport{
public void save(Cart cart) {
getHibernateTemplate().saveOr
Update(cart);
}
}
Kode program untuk pengambilan objek
dari basis data ditulis sebagai berikut:
 Mengambil objek cart sesuai dengan
id tertentu
public Cart getById(Long cartId) {
Cart cart = (Cart)
getHibernateTemplate().
load(Cart. class, cartId);
getHibernateTemplate().initialize
(cart);
return cart;
}
 Mengambil objek cart berdasarkan
status yang sedang aktif.
Public
Cart
getByStatus
(String
status){
Cart cart = (Cart) getHibernate
Template.find(“from
Cart
c
where
c.status=?”, “active”);
return cart;
}
 Mengambil
objek
detailCart
berdasarkan cart tertentu.
Public
DetailCart
getByCart
(Cart
Cart){
DetailCart detailCart = (Detail
Cart) getHibernateTemplate.find(“from
CartDetail
cd
left
join
fetch
cd.cart”);
return detailCart;
}
 Mengambil semua objek cart.
public List<Cart> getAll() {
return
getHibernateTemplate().
find("from Cart");
}
Kode program untuk menghapus objek
cart:
public void delete(Cart cart) {
getHibernateTemplate().delete
(cart);
}
4 Penyederhanaan Fungsi Akses Data
Aplikasi Ritel ERP pada penelitian ini
terdiri atas 50 class DTO yang masingmasing mempunyai interface DAO untuk
akses dan manipulasi data seperti insert,
select, atau delete. Agar mudah diakses,
semua DAO dikumpulkan berdasarkan
submodul ERP ke dalam interface Service.
Interface
Service
merupakan
implementasi dari facade pattern, yaitu
menyederhanakan
fungsi-fungsi
yang
terlihat rumit dengan mengelompokkan
fungsi-fungsi tersebut ke dalam beberapa
interface sehingga menghasilkan fungsi
yang lebih sederhana dan mudah digunakan.
Proses penyederhanaan 50 class DTO
menghasilkan tujuh interface Service,
13
lain AccountPayableService,
AccountReceivableService,
Admin
GeneralLedgerService,
Service,
InventoryService, OrderService, dan
PurchaseService. Proses memasukan
DAO ke dalam Service menggunakan
antara
5 Membuat Skema Basis Data.
teknik Inversion of Control oleh Spring
Framework. Teknik IoC untuk Service
dapat dilihat pada Lampiran 6.
Properti <prop key = "hibernate.
hbm2ddl.auto">
${hibernate.
hbm2ddl.auto} </prop> adalah property
untuk membuat skema basis data. Variabel
${hibernate.hbm2ddl.auto} merujuk
pada properti hibernate.hbm2ddl.auto
pada file jdbc.properties. nilai
variabelnya adalah create. Ada beberapa
Implementasi dari semua DAO pada
Service dituliskan sebagai berikut:
public
class
OrderServiceImpl
implements OrderService {
DebiturDao orderDebiturDao;
CartDao orderCartDao;
}
Objek Service adalah properti yang
akan diakses oleh lapisan aplikasi dalam
proses pengaksesan basis data. Akan tetapi,
sebelumnya dilakukan teknik Declarative
Transaction terhadap Service dengan
menerapkan konsep proxy pattern, yaitu
pola yang merancang suatu objek mewakili
kontrol atau akses objek lain bertindak
seolah-olah objek tersebut melakukannya
Declarative Transaction merupakan
suatu teknik untuk medeklarasikan semua
transaksi dalam suatu file konfigurasi untuk
menangani semua proses transaksi tanpa
harus membuat kode-kode program untuk
menangani transaksi secara eksplisit. Proses
Declarative Transaction ditulis pada file
hibernate.ctx.xml.
Proses Declarative Transaction dimulai
dengan mengatur transaksi oleh objek
session. Objek session yang digunakan
saat transaksi dikendalikan oleh class proxy
yang dihasilkan melalui teknik Declarative
Transaction. Ketika lapisan aplikasi
memanggil Service untuk mengakses basis
data, method Service tidak mengakses
basis data secara langsung. Akan tetapi
Service memanggil moduleXXXService
pada file hibernate.ctx.xml untuk
membuat class proxy yang berisi fungsifungsi transaksi (begin, commit, rollback).
Fungsi-fungsi transaksi tersebut dimasukan
ke dalam Session melalui method
getHibernateTemplate, sehingga tidak
perlu menuliskan proses transaksi secara
programatik
mengendalikan
Session,
karena transaksi dilakukan secara deklaratif
oleh class proxy melalui method
getHibernateTemplate.
pilihan yang bisa digunakan untuk properti
hbm2ddl.auto,
yaitu
create-drop
artinya Hibernate akan membuat semua
tabel
pada
saat
inisialisasi
sessionFactory.
Begitu
sessionFactory ditutup, semua tabel
akan dihapus. Pilihan yang ke dua adalah
create
artinya
pada
saat
sessionFactory
dijalankan
akan
membuat semua tabel dan pada saat
sessionFactory
ditutup tabel yang
dihasilkan tidak akan dihapus.
Selain properti hbm2ddl.auto, yang
digunakan pada proses pembuatan skema
basis
data
adalah
properti
hibernate.show_sql.
Properti
hiberntae.show_sql akan menampilkan
SQL
yang
digunakan
saat
query
menggunakan HQL. Skema basis data yang
dihasilkan digambarkan pada Lampiran 6.
6 Menyatukan
Lapisan
dengan Lapisan Aplikasi
Persistensi
Framework yang digunakan pada lapisan
aplikasi dan presentasi adalah Java Server
Faces (JSF). JSF adalah UI (User Interface)
framework untuk aplikasi Java berbasis web
dengan konsep MVC yang mendukung user
interface berbasis komponen. Setiap action
yang dilakukan memerlukan class controller
atau backing bean. Pada class controller
biasanya dilakukan proses pengaksesan
terhadap basis data.
Class controller yang akan mengakses
atau memanipulasi data memanggil method
Service sesuai data yang diperlukan.
Misalnya jika diperlukan data Item, maka
DAO yang berisi method untuk mengakses
data Item disimpan pada ItemDao,
kemudian ItemDao dimasukan ke dalam
InventoryService. Oleh karena itu,
untuk mengakses data Item dipanggil
InventoryService.
Dan
terakhir
mengatur konfigurasi controller untuk JSF
pada file faces-config.xml. method
Service yang digunakan oleh controller
14
dideklarasikan pada file konfigurasi facesconfig.xml.
Contoh class controller yang mengakses
data adalah seperti berikut:
1
2
3
4
5
6
7
8
9
10
11
12
public class InventoryController {
private InventoryService
inventoryService;
private Item item;
@PostConstruct
public void initBean(){
}
public String save(){
item.setStatus("active");
InventoryService.saveItem (item);
return "success";}
}
Method initBean pada baris lima dan
enam
yang
dianotasi
oleh
@PostConstruct, artinya method ini
dipanggil
setelah
constructor
ListInvController
dipanggil yang
bertujuan inisialisasi data pada halaman
tampilannya. Class Controller di atas
bertugas untuk menyimpan objek item ke
dalam basis data seperti dituliskan pada
baris sepuluh
Class Controller yang telah dibuat
dideklarasikan pada file konfigurasi facesconfig.xml seperti berikut:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<managed-bean>
<managed-bean-name>
InventoryController
</managed-bean-name>
<managed-bean-class>
ilkom.erp.web.controller.
inventory.InventoryController
</managed-bean-class>
<managed-bean-scope>
Request
</managed-bean-scope>
<managed-property>
<property-name
inventoryService
</property-name>
<value>
#{moduleInventoryService}
</value>
</managed-property>
</managed-bean>
Baris ke tiga merupakan penulisan
deklarasi nama controller yang akan
dipanggil pada lapisan presentasi. Nama
controller tersebut berisi class controller
yang didefinisikan pada baris ke enam dan
baris ke tujuh. Properti yang dipunyai
controller tersebut didefinisikan pada baris
ke 12 sampai baris ke 19.
Evaluasi
Proses pemetaan menggunakan ORM
dituliskan dengan kode sederhana, hal ini
sangat membantu pihak pengembang dalam
melakukan query data. ORM menghilangkan
kode-kode exception dan native query yang
terlihat berantakan dan tidak terstruktur.
ORM
mengabstraksi
penggunakan
Relational Data Base Management System
(RDBMS), sehingga mendukung jenis
RDBMS manapun. Query yang digunakan
tidak menurut pada satu jenis RDBMS,
melainkan menggunakan query language
yang disediakan oleh ORM.
Pemanfaatan konsep design pattern
menghasilkan kode program yang lebih rapi
dan terstruktur, serta memudahkan untuk
proses integrasi antara lapisan basis data dan
lapisan aplikasi. Dengan penerapan konsep
design pattern, kode program aplikasi dapat
dengan
mudah
dipelihara
untuk
pengembangan
aplikasi
selanjutnya.
Perbedaan fungsi akses data tanpa
menggunakan ORM, teknik Inversion of
Controls,
dan
teknik
Declarative
Transaction, akses data menggunakan ORM
tetapi tanpa penerapan teknik Inversion of
Controls
dan
teknik
Declarative
Transaction, dan fungsi akses data
menggunakan ORM, Inversion of Controls,
dan teknik Declarative Transaction dapat
dilihat pada Lampiran 7.
Kekurangan dari konsep ORM yang
diterapkan dalam pengembangan sistem
ERP yaitu apabila terjadi perubahan,
penambahan, dan pengurangan domain
model harus meliputi seluruh aspek dari
mulai pembuatan DTO, DAO, Service,
dan deklarasi pada file konfigurasi.
KESIMPULAN DAN SARAN
Kesimpulan
Pada penelitian ini, tidak semua aspek
ketidaksesuaian
ditemukan.
Aspek
ketidaksesuaian
yang
muncul
pada
penelitian ini hanya meliputi empat aspek,
yaitu aspek granularity, identitas, navigasi
data, dan asosiasi antarentitas. Implementasi
konsep ORM terbukti dapat menghilangkan
ketidaksesuian
yang
muncul
karena
perbedaan antara aplikasi yang dibangun
dengan pendekatan berorientasi objek dan
basis data relasional yang digunakan.