Apa itu Castle Windsor, dan mengapa saya harus peduli?

Saya seorang pengembang Windows lama, setelah memotong gigi saya pada win32 dan COM awal. Saya telah bekerja dengan .NET sejak tahun 2001, jadi saya cukup lancar dalam C # dan CLR. Aku belum pernah mendengar tentang Castle Windsor sampai aku mulai berpartisipasi dalam Stack Overflow. Saya telah membaca panduan "Memulai" Castle Windsor, tetapi itu tidak mengklik.

Ajari anjing tua ini trik baru, dan beri tahu saya mengapa saya harus mengintegrasikan Castle Windsor ke dalam aplikasi perusahaan saya.

Castle Windsor adalah inversi alat kontrol. Ada yang lain seperti itu.

Ini dapat memberi Anda objek dengan dependensi pra-dibangun dan pra-kabel di sana. Seluruh grafik objek dibuat melalui refleksi dan konfigurasi daripada operator "baru".

Mulai di sini: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Bayangkan Anda memiliki kelas pengiriman email. Pengirim Email. Bayangkan Anda memiliki WorkflowStepper kelas lain. Di dalam WorkflowStepper Anda perlu menggunakan EmailSender.

Anda selalu bisa mengatakannya new EmailSender().Send(emailMessage);

tapi itu - penggunaan new- menciptakan COUPLING KETAT yang sulit diubah. (Bagaimanapun, ini adalah contoh kecil yang dibuat-buat)

Jadi bagaimana jika, alih-alih membetulkan bocah nakal ini di dalam WorkflowStepper, Anda hanya meneruskannya ke konstruktor?

Jadi, siapa pun yang memanggilnya harus membuat EmailSender baru.

new WorkflowStepper(emailSender).Step()

Bayangkan Anda memiliki ratusan kelas kecil ini yang hanya memiliki satu tanggung jawab (google SRP) .. dan Anda menggunakannya di WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Bayangkan tidak khawatir tentang detail EmailSendersaat Anda menulis WorkflowStepperatauAlertRegistry

Anda hanya khawatir tentang kekhawatiran yang sedang Anda tangani.

Bayangkan seluruh grafik (pohon) objek dan dependensi ini ditransfer pada RUN TIME, sehingga ketika Anda melakukan ini:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

Anda mendapatkan real deal WorkflowStepperdengan semua dependensi yang secara otomatis terisi di mana Anda membutuhkannya.

Tidak ada new

Itu terjadi begitu saja - karena ia tahu apa yang perlu apa.

Dan Anda dapat menulis lebih sedikit cacat dengan kode KERING yang dirancang lebih baik dengan cara yang dapat diuji dan diulang.

Mark Seemann menulis dan buku hebat tentang DI (Dependency Injection) yang merupakan bagian dari IOC. Dia juga membandingkan sejumlah kontainer. Saya tidak bisa merekomendasikan buku ini cukup. Nama buku itu adalah: "Injeksi Ketergantungan pada .Net" https://www.manning.com/books/dependency-injection-in-dot-net

Saya pikir IoC adalah batu loncatan ke arah yang benar di jalan menuju produktivitas yang lebih besar dan kenikmatan tim pengembangan (termasuk PM, BA dan BOs). Ini membantu untuk membuat pemisahan kekhawatiran antara pengembang dan pengujian. Ini memberi ketenangan pikiran ketika membuat arsitektur yang memungkinkan fleksibilitas karena kerangka kerja bisa masuk dan keluar.

Cara terbaik untuk mencapai tujuan yang diambil IoC (CW atau Ninject dll.) Adalah untuk menghilangkan politik # 1 dan # 2 menghilangkan kebutuhan bagi pengembang untuk menggunakan fasad pemahaman yang salah ketika berkembang. Apakah kedua solusi ini tampaknya tidak terkait dengan IoC? Mereka :)

Castle Windsor is Dependency Injection container.Artinya dengan bantuan ini Anda dapat menyuntikkan dependensi dan menggunakannya tanpa membuatnya dengan bantuan kata kunci baru. mis. Pertimbangkan Anda telah menulis repositori atau layanan dan Anda ingin menggunakannya di banyak tempat, Anda harus mendaftarkan layanan / repositori Anda terlebih dahulu dan Anda dapat mulai menggunakannya setelah menyuntikkannya di tempat yang diperlukan. Anda dapat melihat tutorial di bawah ini yang saya ikuti untuk mempelajari kastil windsor.

tautan .

Semoga ini bisa membantu Anda.

Sederhananya. Bayangkan Anda memiliki beberapa kelas yang terkubur dalam kode Anda yang membutuhkan beberapa nilai konfigurasi sederhana untuk melakukan tugasnya. Itu berarti semua yang membuat instance dari kelas itu perlu untuk mendapatkan dependensi tersebut, jadi Anda biasanya harus refactor banyak kelas di sepanjang jalan untuk hanya memberikan sedikit konfigurasi ke tempat instance dibuat.

Jadi baik banyak kelas yang perlu diubah, Anda mengelompokkan nilai-nilai konfigurasi menjadi satu kelas konfigurasi besar yang juga buruk ... atau terburuk masih pergi Service Locator!

IoC memungkinkan kelas Anda untuk mendapatkan semua dependensinya tanpa kerumitan itu, dan mengelola contoh-contoh kehidupan secara lebih eksplisit juga.