RonaldWidha

percaya sama occam razor
See also: Other Geeks@INDC

November 2009 - Posts

Cara Memakai Visual Studio Database Edition GDR dalam situasi beneran

Di post sebelumnya: Visual Studio Database Edition GDR untuk bekerja dengan database dalam development team, aku menjelaskan konsep database development menggunakan Visual Stuio Database Edition GDR.

Di post ini aku ingin menjelaskan bagaimana cara memakai Visual Studio Database Edition GDR ini dalam kerjaan sehari-hari, bukan sekedar demo doank.

Setup – biasanya dilakukan oleh si Team Lead (atau senior dev)

Kembali seperti di post aku sebelumnya (kesempatan terakhir untuk ngeklik dan ngebaca artikelnya sebelum makin ga nyambung), aku menuntut untuk setiap developer bisa memiliki instalasi databasenya masing2 (isolated database environment).

Dalam cara kerja ini, kita harus memulai database project di Visual Studio Database Edition GDR seperti berikut:

  1. Create database baru untuk aplikasi di development box kamu (di mana visual studio berjalan). Atau kalo ini bukan green field project, make sure kamu punya database instancenya di development box lanjut langsung ke step 2. Kita akan nge-refer database instance ini sebagai development database mulai dari sekarang.
  2. Buka Visual Studio Database Edition GDR, klik new Project. Pilih Database Projects > SQL Server 200x (sesuai dengan database engine kamu) dan pilih SQL Server 200x Wizard.

    Wizard ini bakal nanyain kamu beberapa pertanyaan penting untuk memulai seperti: import existing schema dengan opsi-opsi tertentu, collation settings, deployment settings dsb.

    Kalo kamu nge-generate development database dari kode (dengan code smith atau subsonic misalnya), atau kalo kamu sudah punya aplikasi yang menggunakan database tersebut, rekomendasi aku adalah untuk add database project ini ke dalam solution aplikasi kamu. Tujuannya adalah nge-ikat versioning antara kode dengan databasenya.
  3. Di langkah kedua kamu akan ditanyakan “what type of project would you like to create?”. Karena aku ingin isolated database environment mari kita pilih “a database project to manage changes to a user-defined database
  4. Di langkah keempat, pilih import existing schema dan pilih database aplikasi kamu yang berjalan di dev box.
  5. Di langkah terakhir wizard, kamu set up target connection kamu ke database instance yang sama. Tick “always re-create database’”. Dengan pilihan itu kita bakal memastikan development database selalu sinkron dengan database project kita.

    Langkah yang terpenting di sini adalah untuk me-rename nama server kamu dari server instance name ke (local). Misalnya: karena aku pake SQL Express maka server instance aku (local)\SQLExpress. Ini dikarenakan connection string target database disimpan di project file (.dbproj) yang berarti memaksa seluruh team untuk memiliki connection strings yang sama. Dengan menggunakan (local) maka seluruh team bisa memakai 1 connection strings saja.
  6. Sekarang kita sudah punya database project di solution kita.
  7. Buka Solution Explorer > Schema Comparisons > Add new Schema Comparison.
    Namakan: FromDevToModel.scmp
    Set Source Schema ke Development Database (jangan lupa set nama server dengan nama local supaya bisa digunakan oleh semua team member yang lain).
    Set Target Schema ke Database Project

    Liat options comparenya, dan pilih object types yang kamu berharap para dev bakal nge-update seperti tables, functions, stored procs dsb. Ibaratnya ini ignore list di Subversion atau TFS.

    Ini akan dipakai untuk nge-sync perubahan yang developers lakukan ketika development dari Development database ke dalam Database Project.
  8. Bikin 1 Schema comparison lagi, Solution Explorer > Schema Comparisons > Add new Schema Comparison
    Namakan: FromModelToDev.scmp
    Set Source Schema ke Database Project
  9. Set Target Schema ke Development Database.

    Ini akan dipakai untuk nge-sync perubahan yang dilakukan oleh developer lain dari source control ke dalam Development Database.

  10. add Development database kita ke Server explorer. Ini akan memudahkan kita untuk menciptakan table tanpa menulis 1 line T-SQL pun.

Nah, setelah melewati langkah-langkah tadi kita sekarang sudah memiliki solution yang berisi kode aplikasi kita, begitu jg database project yang mengontrol development database. Kita cukup melakukan ini sekali dalam 1 project.

Untuk para programmer yang lain

Tugas berat sudah diemban oleh si Team Lead (atau Senior Dev). Langkah terpenting untuk para team members sekarang adalah untuk memiliki sql server instance dengan nama yang sama supaya seluruh team bisa memakai project file yang sama.

Sekarang mari kita ngebahas gimana siklik developmentnya

Development

Step 1: Database Development pake Server explorer

Aku bukan a hardcore DBA. Jadi urusan alter-mengalter database aku biasanya mengandalkan tool seperti Visual Studio Server Exploerer atau SQL Management Studio Express untuk membantu aku. Dengan Visual Studio Database Edition GDR kita bisa tetap melakukan hal yang sama.

Bikin table, relationship, primary key, foreign key, stored procedure baru atau bahkan lakukan refactoring untuk menyelesaikan tugas kamu.

Step 2: Masukkan perubahan yang baru kamu bikin ke dalam Database Project kita

Setelah kita sudah menyelesaikan perubahan database kita, gunakan Compare Schema untuk memasukkan schema yang baru ke dalam database project.

Gunakan FromDevToModel schema comparison. Dan kita bisa akan melihat update yang baru saja kita lakukan seperti di bawah ini.

image

image

Sepertinya aku baru aja nambahin Schema, dan Table baru.

Klik Writes Updates dan lanjut step 3.

Step 3: persiapan Check in

Seperti team member yang baik, kita ga mau menggangu kerjaan team member yang lain dengan nge-break Continuous Integration build. Jadi setelah membuat perubahan kamu, get latest source code termasuk database project dari version control. Merge conflict yang kamu temuin, lalu lakukan Compare Schema database project yang baru dengan Development Database kamu FromModelToDev.scmp.

Kalo kamu nemuin perbedaan, klik Write Updates untuk nge-update Development Database kamu sesuai dengan Database Project.

Ini jg kesempatan untuk ngejalanin unit test dan Database unit test kita untuk memastikan ga ada unit test yang rusak.

Step 4: check in

Akhirnya kita bisa check in, dan berharap ga ada yang teriak2 “Woyy database-nya rusakk nihhhh gara-gara check in elooo!!”.

Di post berikut mungkin aku akan membahas soal deployment ke production, database unit test, ngegenerate test data dan juga gimana cara nambahin default lookup value ke table baru kita.

Semoga berguna.

Share this post: | | | |
Visual Studio Database Edition GDR untuk bekerja dengan database dalam development team

Aku merasa Visual Studio Database Edition GDR adalah salah satu tool yang paling berharga untuk bekerja dengan database. Sayangnya tidak banyak team yang memakai tool ini, padahal bisa bener-bener membantu dalam menghadapi software development yang menggunakan database.

Bekerja dengan database dalam team itu gampang-gampang susah. Setiap kali aku masuk team, pasti ada aja cara unik gimana mereka ngatur development database. Ada yang jalur resmi lewat DB Admin, ada yang 1 team nge-share 1 development database dan ada jg yang setiap developernya punya database yang terisolasi di komputer masing2.

Aku paling suka cara yang terakhir aku sebut: setiap developer punya database masing2. Dengan ngelakuin ini kita bisa nyoba-nyoba refactor database tanpa takut ngeganggu kerjaan orang lain. Begitu kita yakin apa yang kita mau ubah, kita bisa generate update scriptnya berupa migration script. Ini cara yang serupa seperti di Rails dengan konsep migration-nya. Program seperti DBDeploy.Net atau Subsonic Migrate Me sangat membantu untuk mengatur migration stepnya, tapi tetap masih mudah mengakibatkan error dan membutuhkan disiplin yang tinggi.image

fig. 1 biasanya kita konsen ke migration steps dari 1 versi database ke yang lainnya

Jeff Atwood Coding Horror menulis approach yang serupa di Get Your Database Under Version Control

Di Sql Management Studio maupun DBDeploy.Net, setiap operasi yang kita lakukan ibaratnya seorang seniman tanah liat yang mengubah permukaan sebuah patung. Bedanya kalo pematung memakai tangan, sementara di dunia database kita memakai T-SQL.

Visual Studio Database Edition GDR dengan fitur2 database-nya berusaha memecahkan masalah yang sama dengan pendekatan yang jauh lebih elegan.

Model based development

Di Visual Studio Database Edition GDR, cara kerja kita sangat berubah walaupun terlihat serupa. Kita selalu bekerja berdasarkan model database itu sendiri.

image
fig.2 di Visual Studio Database Edition GDR kita konsen langsung ke model yang kita tuju

Bekerja dengan model memiliki dua keuntungan yang sangat besar:

Ga perlu mikirin Migration Step

Kita tidak perlu memikirkan bagaimana cara mengubah tabel dengan alter scripts. Kita langsung ngedefinisikan secara deklaratif apa yang mau kita tuju.

Mungkin kamu akan bertanya bagaimana cara mendeklarasi database kalo engga bikin migration step? Apakah kita perlu belajar bahasa baru? Ataukah melalui GUI seperti Access? Untungnya jawabannya tidak untuk keduanya. Microsoft memakai Domain Specific Language yang cocok untuk database dan kita semua sudah kenal yaitu…..drum roll…T-SQL!

Loh? barussan aku bilang ga usah mikirin migration step, tapi koq sekarang pake T-SQL lagi buat ngedeklarasi state sebuah table? Bedanya di sini adalah kita ga pernah bikin alter script lagi, melainkan selalu menggunakan statement Create. Sekelompok statement create kan cuma Data Definition language kan?

image

Lebih kerennya lagi, karena Create statements ini berupa text, kita bisa dengan mudah disimpan di source control untuk kolaborasi. Tampaknya Microsoft sudah belajar dari EF (Vote of no confidence salah satunya mengkritik bagaimana XML model edmx tidak gampang di merge dalam situasi bekerja dengan source control).

Design time validation

Karena semua yang kita bangun adalah model (again, don’t let the T-SQL appearance fool you), Visual Studio mampu melakukan manipulasi pintar untuk nge-validasi error kita saat design time.

Pencet ctrl + shift + b (Build) dan kita akan bisa melihat error dan warning list kita tanpa mengaplikasikan definisi database tersebut ke database instance kita

image fig. 3 Kita bisa melihat bhw Visual Studio mendeteksi 2 column dengan nama yang sama dan warning bhw sebuah stored procedure mereferensi column yang tidak eksis

Reference

Download Visual Studio Team System 2008 Database Edition GDR R2
Home of the Data Dude

Share this post: | | | |
Pattern apa yang sering dipake?

Kata 'design pattern' banyak dipakai di berbagai macam konteks. Gang of four konsen ke implementasi. Martin Fowler di PoEA konsen ke 'arsitektur'. Aku ga doyan kata arsitektur. Mungkin lebih tepatnya 'higher level stuff' aja (contohnya: Transaction Script - prosedural, MVC, Supervising COntroller, Presenter First, Model-View-ViewModel, Active Record, Table Gateway dsb).

Di level arsitektur untuk aplikasi web

kita cenderung memakai Model-View-Controller atau Supervising Controller (dikenal jg dengan nama Model View Presenter).

Di level data access layer (bagaimana kita menginstansiasi Model)

kita bisa memakai Active Record kalo untuk aplikasi kecil. Atau menggunakan Repository untuk yang lebih ribet.

Guide yang bagus untuk ngestruktur Model adalah buku dari Eric Evans, Domain Driven Design.

Intinya adalah ngebagi model jadi Entity dan Value Object. Pengaksesan Entity dilakukan melalui Repository. Semua objek2 ini diciptakan melalui komunikasi dengan business di konteks yang spesifik (Bounded Context) 

Di level implementasi

Aku ngerasa kita harus hati2 untuk terjebak dalam design pattern di level implementasi. Kent Beck memakai term 'Code Smell'. Ini adalah saat yang tepat untuk mencari pattern yang tepat untuk ngebersihin kode kamu.

 

Daripada mikirin pattern apa yang sering dipakai…

gimana kalo konsen ke prinsip OO seperti dari Robert Martin, SOLID

S = single responsibility principle

setiap kelas jelas responsibilitynya dan sesuai dengan namanya. alhasil class jadi pendek2, ga banyak properties, dan ga banyak method. jadi: fokus!

O = open closed principle

kode itu ideal nya open for extension tapi closed for modification. buat nambah fitur ga perlu ngubah kode yang ada, tapi tinggal diinjek dengan kode baru.

L = Liskov subtitution principle

ini menentukan gimana cara bikin hierarki parent / subclass berdasarkan return type dan parameter method2 yand di override. return type harus contravariant, dan parameter harus covariant. jujur, aku masi agak struggling mengaplikasikan prinsip ini.

I = Interface segregation principle

satu objek lebih baik punya banyak interface yang spesifik daripada 1 interface yang sangat besar dan generik. misalnya daripada IProfileProvider, mendingan IMemberDetailsProvider, IAuthorizationProfile, IAuthenticationProvider dsb.

D = dependcy injection principle

dependency sebuah kelas harus secara explisit distate dan implementasinya diberikan oleh penggunanya. intinya gini. Kalo sebuah Repository butuh Database class, Repository ga boleh nge-instansiasi Database objeknya sendiri. Biasanya teknik ini digabungin sama Inversion of Control Container atau Service Locator.

Semoga berguna.

Share this post: | | | |