Pertanyaan Tips strategi untuk mempartisi rakitan dan ruang nama


Kerumitan yang sangat umum untuk arsitek teknis adalah membagi aplikasi dalam rakitan dan ruang nama.

  • Sidang dapat dipartisi menurut: penyebaran, kinerja, dan batas keamanan.
  • Namespaces dapat dipartisi menurut batas aplikasi logis.

Juga: ruang nama dapat menjangkau beberapa rakitan.

Saya memiliki pengalaman buruk dalam sebuah proyek di mana kami mempartisi majelis sesuai unit logis dari aplikasi. Keputusan ini berakhir dengan file solusi dengan 30 atau 40 proyek! Loadtime file solusi utama adalah sekitar. 5 menit!!! Ini berakhir dengan buang-buang waktu, pff ...

Skenario sebaliknya adalah untuk menahan semua kode dalam 1 perakitan dan partisi ketika benar-benar diperlukan.

Apakah Anda memiliki kiat tambahan atau praktik terbaik terkait masalah ini?


5
2018-03-13 14:27


asal


Jawaban:


Saya membagi kode menjadi rakitan terpisah hanya ketika saya perlu menggunakannya kembali untuk dua aplikasi yang berbeda (cukup banyak). Jadi saya mulai dengan semuanya dalam satu proyek, dan ketika kebutuhan untuk menggunakan kembali kode menjadi jelas saya membuat perakitan baru dan memindahkan kode (kadang-kadang yang jelas dari awal, misalnya ketika Anda perlu memiliki aplikasi web dan memenangkan formulir melakukan hal yang sama benda).

Kembali. Namespaces, saya lebih suka memilikinya dipartisi dengan baik dalam sebuah majelis, jadi jelas di mana setiap kelas memiliki dan apa yang seharusnya digunakan.


1
2018-03-13 14:34



Anda dapat membagi kelas dengan Namespaces dan menggunakan folder jika Anda mau kelompok file sumber bersama untuk perawatan yang lebih mudah. Jika Anda memiliki persyaratan keamanan dan rakitan tertentu harus melalui pemrosesan khusus seperti Obfuscation misalnya, maka Anda mungkin perlu memisahkannya ke proyek terpisah.

Kegunaan ulang juga merupakan faktor yang mungkin perlu Anda pertimbangkan ketika memikirkan apakah unit logis perlu mendapatkan proyek sendiri karena Anda mungkin memerlukan proyek ini dalam solusi lain juga.


0
2018-03-13 14:38



Apa yang berhasil dengan baik bagi saya adalah pengelompokan tingkat besar berdasarkan jenis kode, tetapi lebih banyak tingkat makro daripada unit logis yang Anda pisahkan. Contohnya,

  • Engine - apa pun non visual. Kelas dukungan, kode infrastruktur dasar. Semuanya mengacu pada ini.
  • EngineUI - Mengandalkan Engine, dan jelas digunakan untuk UI, tetapi tidak ada yang spesifik untuk satu aplikasi.
  • EngineServer - Mengandalkan engine, yang digunakan oleh (biasanya web) server build.
  • AppCore - Aplikasi fungsi inti spesifik, tidak ada UI.
  • AppUI - UI khusus aplikasi
  • AppClient - Menggunakan AppUI, AppCore, EngineUI, Engine. Aplikasi klien yang sebenarnya.
  • AppServer - Menggunakan AppServer, EngineServer, Engine. Aplikasi server.

Setiap proyek memiliki hierarki ruang nama dan sesekali saya menemukan manfaatnya untuk mengeluarkan banyak kode ke dalam perakitan lain tetapi biasanya hal-hal ini tetap teratur dan dapat dikelola, bahkan ketika ada ratusan file yang terlibat. Terlalu banyak proyek adalah sesuatu yang saya coba hindari. Satu bonus menjaga proyek-proyek ini seminimal mungkin adalah membuatnya jauh lebih mudah untuk benar-benar menggunakan kembali pustaka-pustaka ini dalam proyek-proyek berikutnya (seperti pembuatan pengujian otomatis).

Saya tidak terlalu khawatir tentang kode yang tidak digunakan yang digunakan dari pustaka ini karena saya dapat menggunakan utilitas yang menghapus fungsi yang tidak digunakan untuk membangun akhir, menjaga ukuran file menjadi seminimal mungkin.


0
2018-03-13 14:44



Saya merasa berguna untuk mengatur ruang nama ke dalam hierarki, dan membuat nama perakitan sesuai dengan subnamespace yang mereka kontribusikan. Sebagai contoh, sebuah proyek bernama Womble akan memiliki namespace top-level Womble, dan kemudian mungkin ada majelis yang disebut:

Womble.ClientLibrary.dll
Womble.Controls.dll
Womble.Util.dll
Womble.Interop.dll

Di sini, namespace Womble luar membentang beberapa rakitan, tetapi setiap rakitan memiliki subnamespace unik yang hanya dapat berkontribusi, yang Anda temukan dengan menghapus .dll dari akhir. Itu membuat jauh lebih mudah untuk mengingat apa yang perlu Anda rujuk dan menemukan berbagai hal.

Untuk jumlah rakitan yang sangat besar, pada akhirnya Anda tidak perlu menyimpan semuanya dalam satu solusi. Dalam pengembangan skala besar, membantu memecah produk besar ke dalam subsistem, yang mungkin terdiri dari beberapa rakitan, dan setiap subsistem mungkin akhirnya dikelola oleh tim terpisah, dan dapat memiliki file solusi sendiri. Berbagai tim "merilis" versi baru satu sama lain melalui kontrol sumber, memperlakukan satu sama lain sebagai perpustakaan pihak ketiga.

Saya tidak berpikir ada cara yang keras dan cepat untuk memutuskan bagaimana memecah perangkat lunak menjadi aseemblies. Ada prinsip umum di sini: hal-hal yang berubah karena alasan yang berbeda harus dipisahkan.

Proyek yang sangat besar dapat diperoleh dari fakta bahwa dengan meletakkan barang-barang dalam rakitan terpisah, Anda dapat menambalnya secara terpisah. Anda dapat menghasilkan perbaikan terbaru untuk masalah di Womble.Interop.dll, dan kemudian secara terpisah menghasilkan perbaikan terbaru untuk masalah di Womble.Controls.dll, dan memberikan keduanya kepada pelanggan yang sama, sehingga dalam teori, kedua rakitan itu bisa sepenuhnya dipelihara dan didukung oleh tim yang terpisah, tanpa harus mengkoordinasikan kegiatan mereka secara langsung.

Rakitan terpisah juga menciptakan kejelasan dalam ketergantungan antara kode. Anda dapat melihat pada tingkat yang sangat tinggi (hanya melihat daftar referensi) bagaimana satu bongkahan kode tergantung pada yang lain, dan bagaimana itu bisa digunakan kembali. Jika Anda meletakkan segala sesuatu dalam satu rakitan, mungkin ada kekacauan besar yang tidak beraturan.


0
2018-03-14 10:38



Motivasi

Alasan mengapa saya memposting jawaban terlambat ini adalah bahwa semua jawaban sebelumnya lebih merupakan rekomendasi daripada praktik terbaik yang konsisten.

Sejak bertahun-tahun saya bekerja dalam proyek .NET yang sangat besar dan hanya praktik terbaik yang konsisten yang termotivasi secara strategis dan teknis adalah yang diusulkan oleh tim NDepend.

Pendeknya

Rekomendasi NDepend secara umum sejalan dengan pengalaman Anda untuk tidak menyusun struktur sesuai dengan arsitektur. Ini juga mengandung pertimbangan kapan harus memiliki majelis terpisah dan mengapa. Aturan praktis adalah menggunakan penataan oleh majelis untuk alasan fisik, gunakan ruang nama untuk alasan logis.

Ringkasan praktik terbaik NDepend:

Untuk rakitan dan proyek

  • Mengurangi secara drastis jumlah rakitan basis kode Anda.
  • Buat perakitan baru hanya jika ini dibenarkan oleh persyaratan khusus untuk pemisahan fisik.
  • Dalam proyek Visual Studio, gunakan ‘referensi berdasarkan perakitan’ bukan ‘referensi oleh proyek Visual Studio’.
  • Jangan pernah menggunakan opsi referensi Visual Studio 'Salin Lokal = Benar'.
  • Masukkan semua solusi VS dan Buat file .bat dalam direktori $ rootDir $.
  • Kompilasi semua rakitan dalam direktori: $ rootDir $ \ bin \ Debug dan $ rootDir $ \ bin \ Release
  • Gunakan direktori $ rootDir $ \ bin untuk meng-host kumpulan tes.

Untuk ruang nama

  • Gunakan konsep namespace untuk menentukan batasan komponen.
  • Ruangnama biasanya berisi satu hingga dua lusin jenis, dan memiliki ukuran yang wajar yang cocok dalam rentang 500 hingga 2.000 LoC.
  • Luangkan waktu untuk meratakan komponen basis kode Anda, ini tentunya tugas yang lebih murah dari yang diharapkan, sehingga Pengembalian Investasi   akan tinggi.
  • Periksa secara terus-menerus bahwa grafik ketergantungan komponen di dalam perakitan bersifat asiklik.
  • Jika komponen terlalu besar (> 2.000 LoC), gunakan sub-ruang nama untuk membaginya menjadi kumpulan komponen terkait yang lebih kecil.
  • Pada skala apa pun, kelompokkan komponen antara mediator tingkat tinggi, fitur independen tingkat menengah, basis / domain tingkat rendah.
  • Memiliki set komponen 'levelized' menghilangkan kebutuhan untuk sebagian besar keputusan desain.

Pembacaan mendetail

Mempartisi basis kode melalui rakitan NET dan proyek-proyek Visual Studio

Mendefinisikan. NET Components dengan Namespaces


0
2017-08-25 09:04