Menggunakan ORM atau SQL biasa? [Tutup]


245

Untuk beberapa aplikasi yang saya kembangkan (kemudian dilanjutkan untuk melupakan), saya telah menulis SQL biasa, terutama untuk MySQL. Meskipun saya telah menggunakan ORM dalam python seperti SQLAlchemy , saya tidak bertahan lama. Biasanya itu adalah dokumentasi atau kompleksitas (dari sudut pandang saya) menahan saya.

Saya melihatnya seperti ini: menggunakan ORM untuk portabilitas, SQL biasa jika itu hanya akan menggunakan satu jenis database. Saya benar-benar mencari saran kapan harus menggunakan ORM atau SQL saat mengembangkan aplikasi yang membutuhkan dukungan basis data.

Berpikir tentang itu, akan jauh lebih baik untuk hanya menggunakan pembungkus ringan untuk menangani ketidakkonsistenan basis data vs menggunakan ORM.


Standarisasi, keamanan, pemeliharaan, bahasa abstraksi, DRY, dll
Ben

Performa dengan ORM bisa mendekati SQL, tergantung pada apakah Anda menggunakannya dengan benar dan dengan pengaturan yang benar ... Lihat cara membuat EF6.x 5x lebih cepat: linkedin.com/pulse/…
baHI

Untuk arsitektur ORM dan bagaimana caranya (apa yang harus dihindari), inilah tautan saya yang lain: linkedin.com/pulse/…
baHI

Object-Relational mapping (ORM) sudah sangat populer di banyak bahasa pemrograman dan salah satu alternatif terbaik untuk SQL. Saya terinspirasi dari gaya metode chaining untuk membuat CQL untuk proyek TRIADB saya. healis.eu/triadb/#latest-release
Athanassios

2
Bodoh bahwa pertanyaan ini ditutup.
Mitch Wheat

Jawaban:


169

ORM memiliki beberapa fitur yang bagus. Mereka dapat menangani banyak pekerjaan anjing menyalin kolom database ke bidang objek. Mereka biasanya menangani konversi tipe tanggal dan waktu bahasa ke tipe database yang sesuai. Mereka umumnya menangani hubungan satu-ke-banyak dengan sangat elegan juga dengan membuat objek bersarang. Saya telah menemukan jika Anda mendesain database Anda dengan mempertimbangkan kekuatan dan kelemahan ORM, ini menghemat banyak pekerjaan dalam mendapatkan data masuk dan keluar dari database. (Anda harus tahu cara menangani polimorfisme dan hubungan banyak-ke-banyak jika Anda perlu memetakannya. Dua domain inilah yang menyediakan sebagian besar 'ketidakcocokan impedansi' yang membuat beberapa panggilan ORM 'vietnam ilmu komputer' .)

Untuk aplikasi yang bersifat transaksional, yaitu Anda membuat permintaan, mendapatkan beberapa objek, melintasinya untuk mendapatkan beberapa data dan merendernya di halaman Web, pajak kinerja kecil, dan dalam banyak kasus ORM dapat lebih cepat karena akan men-cache objek itu lihat sebelumnya, yang sebaliknya akan menanyakan database beberapa kali.

Untuk aplikasi yang pelaporannya berat, atau berurusan dengan sejumlah besar baris basis data per permintaan, pajak ORM jauh lebih berat, dan caching yang mereka lakukan berubah menjadi beban memori yang besar dan tidak berguna. Dalam hal ini, pemetaan SQL sederhana (LinQ atau iBatis) atau kueri kode tangan SQL dalam DAL yang tipis adalah cara yang harus dilakukan.

Saya telah menemukan aplikasi skala besar apa pun yang Anda temukan menggunakan kedua pendekatan ini. (ORM untuk CRUD dan SQL / DAL tipis untuk pelaporan).


Bisakah Anda mendefinisikan 'sejumlah besar baris database per permintaan'? Tolong :)
Mosselman

Jadi bisakah saya mengintegrasikan JPA dengan IBatis misalnya ?? Dan membuat mereka berfungsi dalam transaksi yang sama?
Jaime Hablutzel

2
Pertimbangan lain yang tampaknya tidak seorang pun membahas adalah manajemen negara dasar. Seluruh susunan kerangka kerja ini (JSF, JPA, dll) didasarkan pada metode Java get get / set. Ini adalah BANYAK pelat ketel untuk setiap tabel, untuk setiap kolom dan ... inilah anti-pola yang sebenarnya: Hanya untuk mengekspos setiap bidang seolah-olah itu publik. Akibatnya, memiliki metode get / set pada bidang dalam objek / tabel / baris sangat dekat dengan melanggar setiap penyewa penyembunyian informasi dan enkapsulasi. Terakhir, kembali ke manajemen negara ... di mana opsi kekekalan? Bisakah atau haruskah setengah-set objek diizinkan? Tidak ada opsi dengan sebagian besar.
Darrell Teague

2
Saya ingin mengasah dan terutama menyetujui pernyataan kunci dalam jawaban ini. "Untuk aplikasi yang berurusan dengan banyak baris database per permintaan, pajak ORM jauh lebih berat". ORM hanya baik untuk pengembang dan pemeliharaan karena sebagian besar pengembang tidak pandai SQL, tetapi jika Anda benar-benar berbicara tentang kinerja, SQL benar-benar mengalahkannya.
Manachi

"sebagian besar pengembang tidak pandai SQL" ??? Saya akan mengatakan bahwa sebagian besar pengembang tidak tahu cara menggunakan LINQ, kekuatan pohon ekspresi, dan ORM secara umum, pembuatan kode, dan banyak hal lainnya. Tapi tidak, saya tidak punya dasar untuk membuat pernyataan yang kuat.
Adanay Martín

253

Berbicara sebagai seseorang yang menghabiskan sedikit waktu bekerja dengan JPA (Java Persistence API, pada dasarnya API ORM standar untuk Java / J2EE / EJB), yang meliputi Hibernate, EclipseLink, Toplink, OpenJPA dan lainnya, saya akan membagikan sebagian dari saya pengamatan.

  1. ORM tidak cepat. Mereka bisa memadai dan sebagian besar waktu memadai OK tetapi dalam lingkungan latensi rendah volume tinggi mereka tidak-tidak;
  2. Secara umum bahasa pemrograman tujuan seperti Java dan C # Anda memerlukan banyak sekali keajaiban untuk membuatnya bekerja (mis. Menenun waktu di Jawa, instrumentasi, dll);
  3. Saat menggunakan ORM, daripada melangkah lebih jauh dari SQL (yang tampaknya menjadi maksudnya), Anda akan kagum dengan berapa banyak waktu yang Anda habiskan untuk mengubah XML dan / atau anotasi / atribut untuk mendapatkan ORM Anda untuk menghasilkan performant SQL;
  4. Untuk pertanyaan kompleks, sebenarnya tidak ada pengganti. Seperti di JPA ada beberapa pertanyaan yang tidak mungkin ada dalam SQL mentah dan ketika Anda harus menggunakan SQL mentah di JPA itu tidak cantik (C # /. Net setidaknya memiliki tipe dinamis - var - yang banyak lebih bagus dari pada array Object);
  5. Ada banyak sekali "gotcha" saat menggunakan ORM. Ini termasuk perilaku yang tidak disengaja atau tidak terduga, fakta bahwa Anda harus membangun kemampuan untuk melakukan pembaruan SQL ke database Anda (dengan menggunakan refresh () di JPA atau metode serupa karena JPA secara default cache semuanya sehingga tidak akan menangkap database langsung pembaruan - menjalankan pembaruan SQL langsung adalah aktivitas dukungan produksi yang umum);
  6. Ketidakcocokan objek-relasional selalu akan menyebabkan masalah. Dengan masalah semacam itu ada pertukaran antara kompleksitas dan kelengkapan abstraksi. Kadang-kadang saya merasa JPA melangkah terlalu jauh dan mencapai hukum pengembalian yang semakin berkurang di mana kompleksitasnya tidak dibenarkan oleh abstraksi.

Ada masalah lain yang membutuhkan sedikit penjelasan.

Model tradisional untuk aplikasi Web adalah memiliki lapisan ketekunan dan lapisan presentasi (mungkin dengan layanan atau lapisan lain di antaranya tetapi ini adalah dua yang penting untuk diskusi ini). ORM memaksakan pandangan kaku dari lapisan kegigihan Anda ke lapisan presentasi (yaitu entitas Anda).

Salah satu kritik dari metode SQL yang lebih baku adalah bahwa Anda berakhir dengan semua VO (objek bernilai) atau DTO (objek transfer data) yang digunakan hanya dengan satu kueri. Ini disebut-sebut sebagai keuntungan ORM karena Anda menyingkirkan itu.

Masalahnya adalah masalah tidak hilang dengan ORM, mereka hanya naik ke lapisan presentasi. Alih-alih membuat VOs / DTO untuk kueri, Anda membuat objek presentasi khusus, biasanya satu untuk setiap tampilan. Bagaimana ini lebih baik? IMHO tidak.

Saya sudah menulis tentang ini dalam ORM atau SQL: Apakah kita sudah sampai? .

Teknologi ketekunan pilihan saya (di Jawa) hari ini adalah ibatis. Ini adalah pembungkus yang sangat tipis di sekitar SQL yang melakukan 90% + dari apa yang dapat dilakukan JPA (bahkan dapat melakukan pemuatan hubungan yang malas meskipun tidak terdokumentasi dengan baik) tetapi dengan overhead yang jauh lebih sedikit (dalam hal kompleksitas dan kode aktual).

Ini muncul tahun lalu di aplikasi GWT yang saya tulis. Banyak terjemahan dari EclipseLink ke objek presentasi dalam implementasi layanan. Jika kita menggunakan ibatis, akan jauh lebih mudah untuk membuat objek yang sesuai dengan ibatis dan meneruskannya ke atas dan ke bawah tumpukan. Beberapa puritan mungkin berpendapat ini adalah Bad ™. Mungkin begitu (dalam teori) tapi saya katakan: apa itu akan menyebabkan kode lebih sederhana, tumpukan lebih sederhana dan lebih banyak produktivitas.


2
Saya telah terinspirasi untuk mengirim pertanyaan lain (meskipun komunitas wiki) hanya untuk mengumpulkan sumber daya pada hal-hal seperti ini. Mengenai paragraf terakhir: Saya suka kesederhanaan. Mungkin terlalu banyak.
hydrapheetz

3
iBATIS memang bagus, tapi mungkin Anda mau mencoba jOOQ: jooq.sourceforge.net . Fokus utamanya adalah untuk tetap dekat dengan SQL untuk 6 alasan yang Anda sebutkan.
Lukas Eder

5
+1 untuk poin 3. Banyak yang merasa bahwa menggunakan ORM membebaskan Anda dari memiliki pemahaman menyeluruh tentang SQL. Masalahnya adalah begitu Anda bisa / belajar melakukan senam dengan SQL, Anda mungkin akan menemukan diri Anda menjauh dari ORM ... dengan sangat cepat.
Ryan Fernandes

4
Jadi, sekarang ini akhir tahun 2013 dan seperti yang kita semua tahu, tidak ada yang lebih menyesatkan daripada "fakta lama" - jadi bisakah saya bertanya kepada Anda apakah poin Anda masih sama? Jika tidak, alangkah baiknya jika Anda bisa menulis blogpost / perbarui jawaban Anda sesuai.
Dominik

3
var tidak menghasilkan tipe dinamis .NET, variabel dengan kata kunci dinamis adalah tipe dinamis dalam .NET. var masih mengetik statis. Lihat stackoverflow.com/questions/961581/…
Fazi

45

Saya katakan SQL sederhana untuk R eads, ORM untuk CUD .

Kinerja adalah sesuatu yang selalu saya khawatirkan, khususnya dalam aplikasi web, tetapi juga pemeliharaan kode dan keterbacaan. Untuk mengatasi masalah ini saya menulis SqlBuilder .


1
Apa itu CUD? Saya tidak dapat menemukan definisi.
Kimchi Man

27
@ KimchiMan CRUD tanpa R.
Max Toro

3
CUD - Buat, perbarui, hapus.
Gabungkan

14

ORM bukan hanya portabilitas (yang agak sulit untuk dicapai bahkan dengan ORM, dalam hal ini). Apa yang diberikannya pada dasarnya adalah lapisan abstraksi di atas toko yang gigih, ketika alat ORM membebaskan Anda dari penulisan kueri SQL boilerplate (dipilih oleh PK atau dengan predikat, sisipan, pembaruan, dan penghapusan) dan memungkinkan Anda berkonsentrasi pada domain masalah.


3
Saya sedang memikirkan sesuatu yang lebih dekat dengan portabilitas di seluruh rasa basis data. Saya seharusnya tidak mengirim pertanyaan larut malam.
hydrapheetz

1
Itulah tepatnya yang saya katakan: bahkan skenario paling mendasar pun berpotensi mengalami kesalahan dalam DBMS yang berbeda - misalnya, penanganan NULL yang berbeda.
Anton Gogolev

ORM memberi Anda lapisan abstraksi atas hubungan antara objek, tetapi tidak ada keuntungan besar sehubungan dengan permintaan boilerplate yang Anda sebutkan. Dalam aplikasi JDBC Anda dapat menulis jenis-jenis pertanyaan dengan sedikit kode dalam superclass abstrak atau kelas utilitas. Tidak perlu mengulangi boilerplate untuk setiap tabel baru.
Kevin Stembridge

11

Setiap desain terhormat akan membutuhkan beberapa abstraksi untuk database, hanya untuk menangani ketidakcocokan impedansi. Tapi langkah pertama yang paling sederhana (dan cukup untuk kebanyakan kasus) yang saya harapkan adalah DAL, bukan ORM kelas berat. Satu-satunya pilihan Anda bukanlah yang ada di ujung spektrum.


EDIT dalam menanggapi komentar yang meminta saya untuk menggambarkan bagaimana saya membedakan DAL dari ORM:

DAL adalah apa yang Anda tulis sendiri, mungkin mulai dari kelas yang hanya merangkum tabel dan memetakan bidangnya ke properti. ORM adalah kode yang tidak Anda tulis atau mekanisme abstraksi yang disimpulkan dari properti lain skema dbms Anda, kebanyakan PK dan FK. (Di sinilah Anda mencari tahu apakah abstraksi otomatis mulai bocor atau tidak. Saya lebih suka memberi tahu mereka dengan sengaja, tetapi itu mungkin hanya preferensi pribadi saya).


2
Di mana Anda menarik garis antara apa itu DAL dan apa itu ORM?
kekacauan

4
Jadi, jika Anda adalah penulis ORM ORM Anda secara otomatis berubah menjadi DAL? :)
Bombe

DAL = Lapisan Persistensi dan ORM adalah alat yang Anda gunakan di dalam DAL Anda untuk melakukan operasi CRUD ke dalam penyimpanan data.
Vahid Ghadiri

7

Setiap alat memiliki tujuan dan visinya. Saya telah membuat http://www.jooq.org/ tepat sesuai dengan kebutuhan Anda, meskipun iBatis mungkin merupakan solusi yang baik untuk Anda juga.

jOOQ memiliki fitur-fitur ORM dasar, tetapi terutama berfokus pada hal-hal yang saya kira paling dibutuhkan oleh kebanyakan pengembang, ketika mencoba menemukan ORM terbaik untuk kebutuhan mereka:

  • pembuatan kode
  • pengikatan variabel (itu menyakitkan di JDBC)
  • Abstraksi sintaks SQL (untuk mencegah kesalahan sintaksis)

Tetapi sering kali mereka bertindak terlalu jauh dan memberikan banyak abstraksi, Anda tidak akan berpikir mereka berlari melawan RDBMS. Di sisi lain, Anda memilih RDBMS justru karena

  • ini adalah sumber data yang kuat
  • SQL dapat melakukan banyak hal baik, performant (seleksi bersarang, serikat, gabungan kompleks, dll). Seringkali ORM tidak dapat melakukan hal-hal ini.
  • Anda dapat menangani sendiri transaksi dan sesi
  • Anda memiliki prosedur UDT dan disimpan

alamat jOOQ persis titik-titik ini. Ini akan bekerja sebaik JDBC, tetapi tanpa rasa sakit.


6

Dilema apakah menggunakan kerangka kerja atau tidak cukup umum dalam skenario pengembangan perangkat lunak modern.

Yang penting untuk dipahami adalah bahwa setiap kerangka kerja atau pendekatan memiliki pro dan kontra - misalnya dalam pengalaman kami, kami telah menemukan bahwa ORM berguna ketika berurusan dengan transaksi yaitu memasukkan / memperbarui / menghapus operasi - tetapi ketika datang untuk mengambil data dengan kompleks hasil menjadi penting untuk mengevaluasi kinerja dan efektivitas alat ORM.

Juga penting untuk memahami bahwa tidak wajib untuk memilih kerangka kerja atau pendekatan dan mengimplementasikan segala sesuatu di dalamnya. Yang kami maksud dengan itu adalah kami dapat memiliki campuran ORM dan bahasa query asli. Banyak kerangka kerja ORM memberikan poin ekstensi untuk plugin dalam SQL asli. Kita harus berusaha untuk tidak terlalu menggunakan kerangka kerja atau pendekatan. Kami dapat menggabungkan kerangka kerja atau pendekatan tertentu dan datang dengan solusi yang tepat.

Anda dapat menggunakan ORM untuk penyisipan, pembaruan, penghapusan, versi dengan konkurensi tingkat tinggi dan Anda dapat menggunakan Native SQL untuk pembuatan laporan dan daftar panjang


3
Mengapa ORM lebih baik untuk konkurensi tinggi?
user359996

6

Kunci yang membuat ORM saya benar-benar terbang adalah pembuatan kode. Saya setuju bahwa rute ORM bukan yang tercepat, dalam hal kinerja kode. Tetapi ketika Anda memiliki tim menengah ke besar, DB berubah dengan cepat kemampuan untuk membuat ulang kelas dan pemetaan dari DB sebagai bagian dari proses build adalah sesuatu yang brilian untuk dilihat, terutama ketika Anda menggunakan CI. Jadi kode Anda mungkin bukan yang tercepat, tetapi pengkodean Anda akan - Saya tahu mana yang akan saya ambil di sebagian besar proyek.

Rekomendasi saya adalah untuk mengembangkan menggunakan ORM sementara Skema masih cair, gunakan profil untuk menemukan kemacetan, kemudian selaraskan area-area yang membutuhkannya menggunakan Sql mentah.

Pemikiran lain, caching yang tertanam dalam Hibernate seringkali dapat membuat peningkatan kinerja besar-besaran jika digunakan dengan cara yang benar. Tidak ada lagi kembali ke DB untuk membaca data referensi.


2
Benar-benar masalah selera pribadi. Bagi saya, pembuatan kode adalah cacat.
dkretz

5
Baca paragraf kedua .... mungkin kelengkapan juga berguna
MrTelly

Pembuatan kode adalah satu-satunya cara untuk menyelesaikan tugas tertentu dengan lebih cepat. Seperti semua alat lainnya, alat ini bisa kuat atau mengarah pada bencana. Secara teknis semua bahasa menghasilkan jenis kode lain.
Banjocat

4

Tidak ada solusi 'satu-alat-cocok-semua', dan ini juga berlaku untuk pertanyaan 'haruskah saya menggunakan atau / m atau tidak? '

Saya akan mengatakan: jika Anda harus menulis aplikasi / alat yang sangat terfokus pada data, tanpa banyak logika, maka saya akan menggunakan SQL biasa, karena SQL adalah bahasa khusus domain untuk aplikasi semacam ini.

Di sisi lain, jika saya menulis aplikasi bisnis / perusahaan yang mengandung banyak logika 'domain', maka saya akan menulis model kelas kaya yang dapat mengekspresikan domain ini dalam kode. Dalam kasus seperti itu, mapper OR / M mungkin sangat membantu untuk berhasil melakukannya, karena dibutuhkan banyak kode pipa dari tangan Anda.


"Tidak ada solusi 'satu-alat-cocok untuk semua'" .. well seharusnya ada.
Rushino

1

Salah satu aplikasi yang saya kembangkan adalah bot IRC yang ditulis dengan python. Modul yang digunakan dijalankan di utas terpisah, tapi saya belum menemukan cara untuk menangani threading saat menggunakan sqlite. Padahal, itu mungkin lebih baik untuk pertanyaan terpisah.

Saya benar-benar harus menulis ulang judul dan pertanyaan sebenarnya. Saya belum pernah menggunakan DAL sebelumnya, dalam bahasa apa pun.


4
Yah, saya berpendapat bahwa Anda harus. SQL mentah di semua tempat itu cukup menjijikkan.
kekacauan

Yah begitulah. Ada perangkat lunak forum tempat saya meretas dari waktu ke waktu yang memiliki banyak mysql_query () dan mysql_result () di semua tempat. Kacang.
hydrapheetz

Hal "aplikasi" apa yang Anda bicarakan?
Zoran Pavlovic

Lucu sekali pertanyaan ini diajukan di aplikasi irc bot dan menjadi seperti itu (panduan yang sangat berguna)! Aplikasi irc bot berada di salah satu ujung skala, dan aplikasi yang memiliki 50-100 + tabel dengan gabungan kompleks dan jutaan baris data dengan 20+ pengembang yang mengerjakannya berada di ujung skala ekstrim yang lain. Saya berani mengatakan ketika sampai pada akhir skala 'aplikasi irc bot', itu hampir tidak penting.
Manachi

1

Gunakan ORM yang berfungsi seperti SQL, tetapi menyediakan pemeriksaan waktu kompilasi dan keamanan tipe. Seperti favorit saya: Objek Pengetahuan Data (pengungkapan: Saya menulisnya)

Sebagai contoh:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

Streaming sepenuhnya. Mudah diatur (tidak ada pemetaan untuk didefinisikan - membaca skema Anda yang ada). Mendukung gabungan, transaksi, permintaan dalam, agregasi, dll. Cukup banyak hal yang dapat Anda lakukan dalam SQL. Dan telah terbukti dari dataset raksasa (seri waktu keuangan) sampai ke hal-hal sepele (Android).


IDE Anda juga dapat memberikan pemeriksaan statis secara langsung (IDEA mengetahui struktur DB selama Anda memberi tahu di mana DB berada / di mana file-file DDL berada, sehingga ia dapat melakukan pemeriksaan jenis / pemeriksaan hubungan / dll dalam kueri / prosedur SQL Anda / apa pun )
Xenos

itu berguna. dapatkah itu dilakukan sebagai bagian dari langkah build / CI? bagaimana cara mengklasifikasikan sql vs string lain? dapatkah ia menangani manipulasi string, atau hanya konstanta string?
Keredson

Saya akan diblokir oleh abBlock, tetapi IntelliJ mem-parsing SQL seperti jetbrains.com/datagrip/features bahasa lain sehingga orang dapat mengintegrasikannya ke CI / CD / build (mungkin dengan meminta tim IJ untuk mengisolasi kode parsing SQL? Mungkin Sonar sudah memiliki parser seperti itu). Parsing membawa tipe data sehingga Anda dapat menambahkan cek pada mereka (saya telah melakukannya dengan plugin khusus), atau memeriksa seperti "apakah kolom JOIN memiliki indeks FK?" dll. Ini akan menjadi perbaikan yang rapi untuk inspeksi SQL asli IJ
Xenos

1

Saya tahu pertanyaan ini sudah sangat lama, tetapi saya pikir saya akan mengirim jawaban kalau-kalau ada yang datang seperti saya. ORM telah datang jauh. Beberapa dari mereka benar-benar memberi Anda yang terbaik dari kedua dunia: membuat pengembangan lebih produktif dan mempertahankan kinerja.

Lihatlah SQL Data ( http://sqldata.codeplex.com ). Ini adalah ORM yang sangat ringan untuk c # yang mencakup semua basis.

FYI, saya penulis SQL Data.


1

Saya ingin menambahkan suara saya ke paduan suara balasan yang mengatakan "Ada jalan tengah!".

Untuk seorang programmer aplikasi, SQL adalah campuran dari hal-hal yang Anda mungkin ingin kontrol dan hal-hal yang Anda hampir pasti tidak ingin dikontrol.

Apa yang selalu saya inginkan adalah layer (sebut saja DAL, ORM, atau micro-ORM, saya tidak keberatan yang mana) yang akan mengambil alih keputusan yang benar-benar dapat diprediksi (bagaimana mengeja kata kunci SQL, ke mana tanda kurung pergi, ketika untuk menciptakan alias kolom, kolom apa yang harus dibuat untuk kelas yang menampung dua pelampung dan int ...), sambil membiarkan saya bertanggung jawab atas aspek tingkat yang lebih tinggi dari SQL, yaitu cara mengatur GABUNGAN, perhitungan sisi server, DISTINCT, BY GROUP, subquery skalar, dll.

Jadi saya menulis sesuatu yang melakukan ini: http://quince-lib.com/

Ini untuk C ++: Saya tidak tahu apakah itu bahasa yang Anda gunakan, tapi semua sama menariknya untuk melihat seperti apa "jalan tengah" itu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.