Konsep MVC dan Efisiensi dalam Struktur Source Program

Bismillah,

Penulis pada kesempatan kali ini akan mencoba menyimpulkan sendiri konsep dari MVC (Model View Controller) yang umumnya digunakan pada pemrograman web berdasarkan pengalaman penulis.

MVC identik dengan OOP, karena penulis menyimpulkan (OOP belum pasti MVC, contoh : JAVA Desktop, akan tetapi MVC sudah pasti berkonsep pada OOP, contoh : Framework Web)

Bisa diumpamakan, seperti halnya sesi pemotretan seorang model busana:

1. Model = Adalah model(gadis) itu sendiri, View = Hasil foto, Controller = Juru foto, Objectnya = Busananya.

2. Yang terjadi di sini adalah, Busana yang sudah tersedia akan disajikan agar dapat terlihat menarik dan fungsional sehingga dapat dilihat oleh para user, maka project yang dijalankan => disiapkanlah gadis sebagai layer yang digunakan untuk mencapai tujuan fungsional akan tetapi project ini belum bisa disajikan secara menarik, oleh karena itu juru foto akan mengambil bagian untuk mengarahkan dan memfasilitasi si gadis agar dapat terlihat menarik, untuk benar – benar terlihat menarik hasil foto harus dicetak agar dapat dilihat oleh user.

3. Hasil foto akan di komentari apakah masih da yg kurang? Jika ada, maka user akan meminta kepada juru foto untuk mengambil foto dari sisi yang di inginkan ataupun untuk mengambil foto dengan gadis ataupun busana yang lain.

Dari ilustrasi di atas dapat disimpulkan bahwa, Model itu sebagai DAO (Data Access Object) yang akan mengolah data, data yang sudah atau akan diolah diatur oleh Controller sebelum akhirnya akan disajikan di dalam View agar dapat digunakan.

Sederhananya, Model => Query Function, Controller => Method Function, View => Layout (HTML, CSS).

Konsep ini sebenarnya adalah untuk memudahkan developer untuk mengembangkan project dan juga untuk mempermudah dirinya ataupun orang lain di dalam maintenancenya. Delevoper ‘immortal’ sebutan penulis, akan membuat project yang strukturnya sangat membingungkan di dalam proses maintenance, terkadang terbersit di dalam pikiran penulis ketika menghadapi struktur project seperti itu ‘Apakah beliau mau mengerjakan project ini seumur hidup? dan juga apakah beliau yakin bahwa beliau akan terus hidup sampai akhir hayat dari siklus hidup sistem tersebut?’.

Maksudnya tidak bisakah kita membuat struktur yang mudah dipahami, seperti:

1. Form index,A,B,C,D.

Yang akan penulis ubah ke dalam:
1.1 ViewIndex, ViewA, ViewB, ViewC, ViewD.
1.2 ControllerIndex, ControllerA, ControllerB, ControllerC, ControllerD.
1.3 ModelA, ModelB, ModelC, ModelD.
1.4 ObjectA, ObjectB, ObjectC, ObjectD.

Jika diperhatikan konsep sederhana di atas maka dalam ViewIndex terdapat rumah utama yang seharusnya ContollerIndex hanya menampung fungsi dari menu utama dan metode utama (Session Role atau inisialisai SSO), misalkan: untuk proses ke ViewA, ControllerIndex hanya membuka halaman tanpa ada ’embel-embel’ lainnya yang seharusnya bisa dilakukan ContollerA pada saat membuka ViewA, dst. Untuk penggunaan Model dan Object pun sekiranya seperti demikian agar untuk proses trace source akan lebih mudah dan proses maintenancepun akan lebih efisien meskipun tanpa si Developer ‘immortal’ tersebut. Perlu diingat, jangan ada proses ’embel-embel’ di dalam suatu bagian yang seharusnya bisa dilakukan di dalam proses perbagian.

Tulisan ini merupakan bagian dari pengalaman penulis serta curhatan penulis yang kesulitan untuk maintenance project si Developer ‘immortal’ ini.😀

Demikian, semoga bermanfaat.🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s