Konfigurasi Xml versus Konfigurasi berbasis Anotasi [ditutup]

Dalam beberapa proyek besar yang saya kerjakan belakangan ini, menjadi semakin penting untuk memilih satu atau yang lain (XML atau Anotasi). Seiring pertumbuhan proyek, konsistensi sangat penting untuk pemeliharaan.

Pertanyaan saya adalah: apa kelebihan konfigurasi berbasis XML daripada konfigurasi berbasis anotasi dan apa kelebihan konfigurasi berbasis anotasi dibanding konfigurasi berbasis XML?

Anotasi dapat digunakan, tetapi bukan satu-satunya solusi untuk mematikan konfigurasi XML. Saya sarankan mencampur keduanya!

Misalnya, jika menggunakan Spring, sepenuhnya intuitif untuk menggunakan XML untuk bagian injeksi ketergantungan aplikasi Anda. Ini menjauhkan ketergantungan kode dari kode yang akan menggunakannya, sebaliknya, menggunakan semacam anotasi dalam kode yang memerlukan dependensi membuat kode mengetahui konfigurasi otomatis ini.

Namun, daripada menggunakan XML untuk manajemen transaksional, menandai metode sebagai transaksional dengan anotasi masuk akal, karena ini adalah informasi yang mungkin ingin diketahui oleh seorang programmer. Tetapi suatu antarmuka akan disuntikkan sebagai SubtipeY bukan SubtypeX tidak boleh dimasukkan dalam kelas, karena jika sekarang Anda ingin menyuntikkan SubtypeX, Anda harus mengubah kode Anda, sedangkan Anda memiliki kontrak antarmuka sebelumnya, jadi dengan XML, Anda hanya perlu mengubah pemetaan XML dan cukup cepat dan tidak menyakitkan untuk melakukannya.

Saya belum pernah menggunakan anotasi JPA, jadi saya tidak tahu seberapa bagusnya, tetapi saya berpendapat bahwa meninggalkan pemetaan kacang ke basis data dalam XML juga bagus, karena objek seharusnya tidak peduli dari mana informasi itu berasal , seharusnya peduli apa yang dapat dilakukannya dengan informasinya. Tetapi jika Anda suka JPA (saya tidak punya expirience dengan itu), tentu saja, lakukanlah.

Secara umum: Jika anotasi menyediakan fungsionalitas dan bertindak sebagai komentar di dalam dan dari dirinya sendiri, dan tidak mengikat kode ke beberapa proses tertentu untuk berfungsi secara normal tanpa anotasi ini, maka pergi untuk anotasi. Misalnya, metode transaksional yang ditandai sebagai transaksional tidak mematikan logika operasinya, dan juga berfungsi sebagai komentar tingkat kode yang baik. Jika tidak, informasi ini mungkin paling baik dinyatakan sebagai XML, karena meskipun pada akhirnya akan mempengaruhi bagaimana kode beroperasi, itu tidak akan mengubah fungsi utama dari kode, dan karenanya tidak termasuk dalam file sumber.

Ada masalah yang lebih luas di sini, yaitu meta-data eksternalisasi vs inline. Jika model objek Anda hanya akan bertahan dalam satu cara, maka meta-data inline (yaitu anotasi) lebih kompak dan mudah dibaca.

Namun, jika model objek Anda digunakan kembali dalam aplikasi yang berbeda sedemikian rupa sehingga setiap aplikasi ingin mempertahankan model dengan cara yang berbeda, maka mengeksternalisasi meta-data (yaitu deskriptor XML) menjadi lebih tepat.

Tidak ada yang lebih baik, dan keduanya didukung, meskipun anotasi lebih modis. Akibatnya, kerangka kerja hair-on-fire baru seperti JPA cenderung lebih menekankan pada mereka. API yang lebih matang seperti Hibernate asli menawarkan keduanya, karena diketahui bahwa keduanya tidak cukup.

Saya selalu berpikir tentang penjelasan sebagai semacam indikator apa kelas mampu, atau bagaimana berinteraksi dengan orang lain.

Konfigurasi pegas XML di sisi lain bagi saya hanya itu, konfigurasi

Misalnya, informasi tentang ip dan port proxy, sudah pasti akan menjadi file XML, itu adalah konfigurasi runtime.

Menggunakan @Autowire, @Elementuntuk menunjukkan kerangka kerja apa yang harus dilakukan dengan kelas adalah penggunaan anotasi yang baik.

Menempatkan URL ke dalam @Webserviceanotasi adalah gaya yang buruk.

Tapi ini hanya pendapat saya saja. Garis antara interaksi dan konfigurasi tidak selalu jelas.

Saya telah menggunakan Spring selama beberapa tahun sekarang dan jumlah XML yang diperlukan pasti membosankan. Antara skema XML baru dan dukungan anotasi di Spring 2.5, saya biasanya melakukan hal-hal ini:

1. Menggunakan "pemindaian komponen" untuk memuat secara otomatis kelas yang menggunakan @Repository, @Service atau @Component. Saya biasanya memberi nama setiap kacang dan kemudian menyatukannya menggunakan @Resource. Saya menemukan bahwa pipa ledeng ini tidak terlalu sering berubah sehingga penjelasannya masuk akal.

2. Menggunakan namespace "aop" untuk semua AOP. Ini sangat bagus. Saya masih menggunakannya untuk transaksi juga karena menempatkan @Transaksional di semua tempat agak membosankan. Anda dapat membuat pointcuts bernama untuk metode pada layanan atau repositori dan sangat cepat menerapkan saran.

3. Saya menggunakan LocalContainerEntityManagerFactoryBean bersama dengan HibernateJpaVendorAdapter untuk mengkonfigurasi Hibernate. Ini memungkinkan Hibernate dengan mudah menemukan kelas-kelas @Entity otomatis di classpath. Lalu saya membuat kacang SessionFactory bernama menggunakan "kacang pabrik" dan "metode pabrik" mengacu pada LCEMFB.

Bagian penting dalam menggunakan pendekatan anotasi saja adalah bahwa konsep "nama kacang" lebih atau kurang hilang (menjadi tidak signifikan).

"Nama kacang" di Musim Semi membentuk tingkat abstraksi tambahan atas kelas pelaksana. Dengan XML, kacang didefinisikan dan direferensikan relatif terhadap nama kacang mereka. Dengan anotasi, mereka dirujuk oleh kelas / antarmuka mereka. (Meskipun nama kacang ada, Anda tidak perlu mengetahuinya)

Saya sangat percaya bahwa menghilangkan abstraksi berlebihan menyederhanakan sistem dan meningkatkan produktivitas. Untuk proyek besar saya pikir keuntungan dengan menghilangkan XML bisa sangat besar.

Saya pikir visibilitas adalah kemenangan besar dengan pendekatan berbasis XML. Saya menemukan bahwa XML tidak seburuk itu, mengingat berbagai alat di luar sana untuk menavigasi dokumen XML (yaitu jendela File Struktur Visual Studio + ReSharper).

Anda tentu dapat mengambil pendekatan campuran, tetapi itu tampak berbahaya bagi saya jika hanya karena, berpotensi, akan menyulitkan pengembang baru pada proyek untuk mencari tahu di mana objek yang berbeda dikonfigurasi atau dipetakan.

Saya tidak tahu; pada akhirnya XML Hell sepertinya tidak terlalu buruk bagiku.

Itu tergantung pada apa saja yang ingin Anda konfigurasi, karena ada beberapa opsi yang tidak dapat dikonfigurasi dengan anotasi. Jika kita melihatnya dari sisi anotasi:

• plus: anotasi kurang banyak bicara
• minus: anotasi kurang terlihat

Terserah Anda apa yang lebih penting ...

Secara umum saya akan merekomendasikan untuk memilih satu cara dan menggunakannya di seluruh bagian produk yang tertutup ...

(dengan beberapa pengecualian: mis. jika Anda memilih konfigurasi berbasis XML, tidak apa-apa menggunakan anotasi @ Autowire. Mencampur, tetapi yang ini membantu keterbacaan dan rawatan)

Ada aspek lain untuk dibandingkan seperti refactoring dan perubahan kode lainnya. ketika menggunakan XML, diperlukan upaya serius untuk membuat refactoring karena Anda harus mengurus semua konten XML. Tetapi mudah saat menggunakan Anotasi.

Cara yang saya sukai adalah konfigurasi berbasis Java tanpa anotasi (atau minimal). http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Saya mungkin salah, tapi saya pikir Anotasi (seperti dalam Java's tag @ dan C # [Atribut]) adalah opsi waktu kompilasi, dan XML adalah opsi run-time. Itu bagi saya mengatakan tidak setara dan memiliki pro dan kontra yang berbeda.

Saya juga berpikir campuran adalah yang terbaik, tetapi juga tergantung pada jenis parameter konfigurasi. Saya sedang mengerjakan proyek Seam yang juga menggunakan Spring dan saya biasanya menyebarkannya ke berbagai pengembangan dan server pengujian. Jadi saya telah membagi:

• Konfigurasi khusus server (Seperti jalur absolut ke sumber daya di server): Spring XML file
• Menyuntikkan kacang sebagai anggota kacang lainnya (atau menggunakan kembali nilai Spring XML dalam banyak kacang): Anotasi

Perbedaan utama adalah Anda tidak perlu mengkompilasi ulang kode untuk semua perubahan konfigurasi khusus-server, cukup edit file xml. Ada juga keuntungan bahwa beberapa perubahan konfigurasi dapat dilakukan oleh anggota tim yang tidak mengerti semua kode yang terlibat.

Dalam lingkup wadah DI, saya menganggap DIOT berbasis anotasi menyalahgunakan penggunaan anotasi Java. Dengan mengatakan itu, saya tidak merekomendasikan untuk menggunakannya secara luas dalam proyek Anda. Jika proyek Anda benar-benar membutuhkan kekuatan wadah DI, saya akan merekomendasikan untuk menggunakan Spring IoC dengan opsi konfigurasi berbasis Xml.

Jika hanya demi Unit-test, pengembang harus menerapkan pola Dependency Inject dalam pengkodean mereka dan mengambil keuntungan dari alat mengejek seperti EasyMock atau JMock untuk menghindari ketergantungan.

Anda harus mencoba menghindari menggunakan wadah DI dalam konteks yang salah.

Informasi konfigurasi yang akan selalu ditautkan ke komponen Java tertentu (kelas, metode, atau bidang) adalah kandidat yang baik untuk diwakili oleh anotasi. Anotasi bekerja dengan sangat baik dalam hal ini ketika konfigurasi merupakan inti dari tujuan kode. Karena keterbatasan pada anotasi, sebaiknya bila setiap komponen hanya dapat memiliki satu konfigurasi. Jika Anda perlu berurusan dengan banyak konfigurasi, terutama yang tergantung pada apa pun di luar kelas Java yang berisi anotasi, anotasi dapat menciptakan lebih banyak masalah daripada yang mereka pecahkan. Akhirnya, anotasi tidak dapat dimodifikasi tanpa mengkompilasi ulang kode sumber Java, jadi apa pun yang perlu dikonfigurasi ulang pada waktu berjalan tidak dapat menggunakan anotasi.

Silakan merujuk tautan berikut. Mereka mungkin berguna juga.

1. Anotasi vs XML, kelebihan dan kekurangan
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Ini adalah pertanyaan klasik 'Konfigurasi versus Konvensi'. Selera pribadi menentukan jawabannya dalam banyak kasus. Namun, secara pribadi saya lebih suka Konfigurasi (berbasis XML) daripada Konvensi. IMO IDE cukup kuat untuk mengatasi beberapa neraka XML yang sering dikaitkan dengan bangunan dan mempertahankan pendekatan berbasis XML. Pada akhirnya, saya menemukan manfaat Konfigurasi (seperti membangun utilitas untuk membangun, memelihara, dan menggunakan file konfigurasi XML) melebihi Konvensi dalam jangka panjang.

Saya menggunakan keduanya. Sebagian besar XML, tetapi ketika saya memiliki banyak kacang yang mewarisi dari kelas umum dan memiliki sifat umum, saya menggunakan anotasi untuk itu, di superclass, jadi saya tidak perlu mengatur properti yang sama untuk setiap kacang. Karena saya sedikit aneh kontrol, saya menggunakan @Resource (nama = "ReferBean") alih-alih hanya hal-hal autowiring (dan menghemat banyak masalah jika saya perlu kacang lain dari kelas yang sama dengan referBean asli) .

Ada beberapa pro dan kontra dari konfigurasi anotasi dari pengalaman saya:

• Ketika datang ke konfigurasi JPA karena dilakukan sekali dan biasanya tidak berubah cukup sering saya lebih suka tetap berpegang pada konfigurasi anotasi. Mungkin ada kekhawatiran tentang kemungkinan untuk melihat gambaran konfigurasi yang lebih besar - dalam hal ini saya menggunakan diagram MSQLWorkbench.
• Konfigurasi xml sangat baik untuk mendapatkan gambaran aplikasi yang lebih besar tetapi mungkin sulit untuk menemukan beberapa kesalahan hingga runtime. Dalam hal ini anotasi Spring @Configuration kedengarannya sebagai pilihan yang lebih baik karena membiarkan Anda melihat gambar yang lebih besar juga dan juga memungkinkan untuk memvalidasi konfigurasi pada waktu kompilasi.
• Mengenai konfigurasi Spring, saya lebih suka menggabungkan kedua pendekatan: gunakan anotasi @Configuration dengan antarmuka Services and Query dan konfigurasi xml untuk dataSource dan konfigurasi spring seperti konteks: pemindaian komponen-paket dasar = "..."
• Tetapi konfigurasi xml bit penjelasan java ketika datang ke konfigurasi aliran (Spring Web Flow atau Lexaden Web Flow) karena sangat penting untuk melihat gambaran yang lebih besar dari seluruh proses bisnis. Dan kedengarannya rumit untuk menerapkannya dengan pendekatan anotasi.

Saya lebih suka menggabungkan kedua pendekatan - anotasi java dan esensial xml minimum yang meminimalkan konfigurasi neraka.

Untuk Spring Framework, saya suka ide untuk menggunakan anotasi @Component dan mengatur opsi "komponen-scan" sehingga Spring dapat menemukan kacang java saya sehingga saya tidak harus mendefinisikan semua kacang saya dalam XML, maupun dalam JavaConfig. Sebagai contoh, untuk kacang jawa tunggal tanpa kewarganegaraan yang hanya perlu ditransfer ke kelas lain (melalui antarmuka idealnya) pendekatan ini bekerja dengan sangat baik. Secara umum, untuk kacang Spring sebagian besar saya telah pindah dari Spring XML DSL untuk mendefinisikan kacang, dan sekarang mendukung penggunaan JavaConfig dan Spring Annotations karena Anda mendapatkan waktu kompilasi memeriksa konfigurasi Anda dan beberapa dukungan refactoring yang tidak Anda miliki. t dapatkan dengan konfigurasi Spring XML. Saya mencampur keduanya dalam kasus langka tertentu di mana saya menemukan bahwa JavaConfig / Annotations tidak dapat melakukan apa yang tersedia menggunakan konfigurasi XML.

Untuk Hibernate ORM (belum menggunakan JPA) saya masih lebih suka file pemetaan XML karena anotasi dalam kelas model domain sampai tingkat tertentu melanggar Arsitektur Bersih yang merupakan gaya arsitektur layering yang telah saya adopsi selama beberapa tahun terakhir. Pelanggaran terjadi karena membutuhkan Lapisan Inti untuk bergantung pada hal-hal terkait kegigihan seperti perpustakaan Hibernate atau JPA dan itu membuat POJO model domain sedikit kurang persistensi. Bahkan Layer Inti tidak seharusnya bergantung pada infrastruktur lain sama sekali.

Namun, jika Arsitektur Bersih bukan "secangkir teh" Anda, maka saya dapat melihat pasti ada keuntungan (seperti kemudahan dan pemeliharaan) menggunakan anotasi Hibernate / JPA di kelas model domain di atas file pemetaan XML yang terpisah.