Salam kenal untuk kakak-kakak yang di sini. Saya member baru ingin tanya tentang struktur aplikasi database dalam delphi yang baik dan benar. Selama ini saya dalam membuat aplikasi yang kecil-kecilan sering pakai data-aware control yang langsung disambungkan ke table. Sekarang saya sedang membuat aplikasi yang agak besaran dan strukturnya seperti ini: Ada beberapa datamodule yang memiliki field connection di mana pada saat create dia akan mengambil connection dari data module utama dan disimpan dalam fieldnya itu. Untuk hampir setiap entity dalam database saya buatkan strukturnya sendiri di unit datamodulenya seperti:

TDataCustomer = record
    CustomerID : Integer;
    CustomerName : String;
    ...
end;

sesuai struktur field yang ada di database. Dan di datamodule itu sendiri ada methodnya seperti:

TDataModuleCustomer = class(TDataModule)
public
    procedure Insert(data : TDataCustomer);
    procedure Update(kodeCustomer : integer; data : TDataCustomer);
    procedure Delete(kodeCustomer : integer);
    ...beberapa procedure/fungsi lagi misal TotalPembelian dsb...
    function SemuaCustomer(ds : TClientDataSet = nil) : TClientDataSet;
    ...beberapa fungsi select lagi...
end;

Di mana fungsi seperti SemuaCustomer akan mengembalikan ClientDataSet yang "fresh" (hasil Create) apabila parameternya nil (defaultnya) atau akan mengisi ClientDataSet yang dimasukkan di parameter apabila parameternya tidak nil. Di setiap procedure Insert/Update/Delete sendiri saya menggunakan kode SQL yang langsung misal:

procedure TDataModuleCustomer.Insert(data: TDataCustomer);
var
  command : TADOCommand;
begin
  command := TADOCommand.Create(nil);
  try
    with command do begin
      Connection := self.Connection;
      CommandText := 'INSERT INTO Customer (CustomerName) VALUES (:CustName)';
      ParamCheck := True;
      Parameters.ParamByName('CustName').Value := data.CustomerName;
      Execute;
    end;
  finally
    command.Free;
  end;
end;

Untuk data entry sendiri aplikasi ini menggunakan edit biasa (untungnya saya tidak disuruh buat entry pakai grid) yang nantinya saat ditekan "Insert" maka kode di form akan mengisi record TDataCustomer dan memanggil method insert dari datamodulenya. Untuk menampilkan data untuk laporan tentunya menggunakan dbgrid dan berbagai data-aware control lainnya tapi datasetnya adalah ClientDataSet hasil pemanggilan method milik datamodule. (untungnya lagi, kok data di laporan tidak diminta bisa diedit). Apabila ada perhitungan yang rumit dilakukan di SQL maka saya lakukan di method saat mengisi ClientDataSet-nya. Mohon para kakak-kakak yang lebih berpengalaman untuk mengkritik habis-habisan (dan disertai saran :) ) struktur aplikasi saya ini. Satu hal yang agak saya sesalkan di sini adalah di mana setiap method dalam datamodule saya ditulis dengan anggapan saya akan memakai ADO (awalnya databasenya adalah Access). Sehingga agak susah untuk nantinya pindah ke database yang tidak didukung oleh driver ADO/OLEDB seperti Firebird (rencananya kalo kepepet sih mau menggunakan ODBC lewat ADO ke Firebird :twisted:)

if it aint broken, dont fix it... hehehe....

>tentang struktur aplikasi database dalam delphi yang baik dan benar. wah ini relatip lah.... TDataCustomer = record CustomerID : Integer; CustomerName : String; ... end; sebaiknya anda pake fitur OOP-nya Delphi , jadi pake class bukan record. soal konsep yg anda paparkan , saya pikir ok walaupun masih sangat basic. harus anda extend frameworknya : 1. kelompokkan class nya jadi single object (turunan TObject), dan object list/container/collection ( turunan TList ) 2. bisa support relasi ( 1-1 atau 1-n atau m-n), pake konsep Owner-Owned. 3. harusnya di class, ada flag/property yg menunjukkan status isi object/record tsb: baru create, ter-edit , terdelete , atau clean, dan waktu di-pass ke DB-layer-nya utk di save/update, prosedurnya bisa generic dan akan melakukan tindakan yg sesuai dengan status tsb. saran saya, klo anda emang baru mulai ( jadi belon banyak invest di framework yg anda bangun ini), mendingan pake konsep OPF yg sdh jadi semisal tiOPF atau InstantObjects. Saya sendiri sdh mulai dengan tiOPF dan setelah mendalami konsepnya, emang enak sih... Business Layer bisa bebas terhadap Presentation Layernya dan banyak kemudahan-kemudahan yg laen - Validasi , Editing, termasuk pilihan DB dan bisa switch dengan cepat. di tiOPF forum , banyak lho yg mau ngebantuin termasuk terhadap pertanyaan-pertanyaan yg dasar. silakan bergabung disana, Atau klo emang mau kembangin framework sendiri, silakan di-diskusi-in disini dan bisa kita sharing-kan....

@mat_koder: harus anda extend frameworknya : 1. kelompokkan class nya jadi single object (turunan TObject), dan object list/container/collection ( turunan TList ) 2. bisa support relasi ( 1-1 atau 1-n atau m-n), pake konsep Owner-Owned. 3. harusnya di class, ada flag/property yg menunjukkan status isi object/record tsb: baru create, ter-edit , terdelete , atau clean, dan waktu di-pass ke DB-layer-nya utk di save/update, prosedurnya bisa generic dan akan melakukan tindakan yg sesuai dengan status tsb.

Wow! Ya inilah bedanya yang niat dan master dengan yang baru mulai. Saya sih setuju aja kalo memang pakai yang seperti itu (OPF/ORM yang pernah saya coba cuma Hibernate untuk Java -- cuma untuk main-main). Tapi sebenarnya niat saya sendiri sih tidak sampai yang segitunya (ORM). Sebenarnya niat saya cuma sebatas mencegah jangan sampai saya atau rekan-rekan saya menaruh banyak logika bisnis dalam form karena mencari dan mengupdatenya kalau berubah nanti susah. Jadi operasi-operasinya saya kelompokkan dalam DataModule yang nanti dipanggil dari form. Meskipun saya buatnya setelah baca Table Data Gateway, Transaction Script dan Table Module tapi rasanya tidak bisa dibandingkan :) Sisi plusnya sih yang ini mudah dimengerti dan rekan-rekan saya kelihatannya juga cukup nyaman kalau disuruh menggunakan method-methodnya atau membuat method tambahan. Penggunaan record sendiri di atas sebenarnya hanya digunakan untuk dua hal: [list=1:17bc148ea4] [:17bc148ea4] Untuk parameter. Kalau parameter Update() ada sebanyak (kolom database) - 1 jelas memanggilnya rumit :). [ :17bc148ea4] Untuk nilai kembalian apabila yang dikembalikan cuma 1 baris misal

if CariCustomer(1234, recCustomer) then writeln(recCustomer.nama);

[/list:o:17bc148ea4]

@mat_koder: saran saya, klo anda emang baru mulai ( jadi belon banyak invest di framework yg anda bangun ini), mendingan pake konsep OPF yg sdh jadi semisal tiOPF atau InstantObjects.

Saya sudah pernah lihat video demo dari InstantObjects. Asyik juga sih kelihatannya. Tapi di webpage tiOPF v. InstantObjects katanya tentang IO "Relations are stored in blobs". Benarkah ini? Kalau benar begitu pasti databasenya sudah tidak bisa dimengerti lagi deh oleh otak manusia :( . tiOPF sendiri saya sudah download dan belum saya pelajari, tapi melihat contoh programnya di http://www.techinsite.com.au/tiOPF/Doc/5_AWorkedExampleOfUsingTheTIOPF.htm (A Worked Example Of Using The tiOPF) program itu butuh 7 class untuk membuat daftar alamat? Kelihatannya kok rumit (bagi saya :) )

@mat_koder: di tiOPF forum , banyak lho yg mau ngebantuin termasuk terhadap pertanyaan-pertanyaan yg dasar. silakan bergabung disana,

Forum tiOPF ini yang alamatnya di mana ya? Yang newsgroup itu kah?

@mat_koder: Atau klo emang mau kembangin framework sendiri, silakan di-diskusi-in disini dan bisa kita sharing-kan....

:shock: Hmm. coba ya... _lmzFramework v0.0.0a "Features" [list:17bc148ea4] [:17bc148ea4] No database independence -- write queries yourself. Each database is different so we invite you to make the best of your particular database by writing all the database code yourself. [ :17bc148ea4] No IDE integration -- we don't pretend to know your preferences in generated code so write the code yourself. Besides, generated code you don't understand is evil. [:17bc148ea4] No "domain objects". You are interfacing with a SQL database -- SQL rows are not objects. "Object mapping" would destroy the power and beauty of SQL. And DOMAIN is for data typing! You (see "No IDE Integration") create records for each row -- they are easy and don't need to be freed. [ :17bc148ea4] Simplicity and ease of understanding -- since we don't write anything for you or provide any code, you can be sure of understanding everything you have in your program (if you comment it well). [/list:u:17bc148ea4] Yeah... tiOPF hati-hatilah! _lmzFramework siap menyerbu :P Kembali ke topik semula... rasanya tiOPF ini pantas dipelajari. Saya harus cari cara agar saya bisa membahas tiOPF ini untuk di kampus :) . Belajar hal yang menarik sekaligus dapat nilai -- siapa yang tak mau :D .