GUI, BLL, Organisasi DAL Dalam Suatu Proyek

Saya membaca tentang lapisan aplikasi, dan ingin menggunakan desain ini dalam proyek saya berikutnya (c #, .Net). Beberapa pertanyaan:

1. Apakah pemisahan lapisan dilakukan melalui ruang nama? Project.BLL. Apa pun, Project.DAL. Apa pun

2. Apakah lebih tepat untuk memisahkan dengan lapisan, maka komponen (Project.BLL.Component1), atau oleh komponen, kemudian lapisan (Project.Component1.BLL)

3. Untuk DAL saya, apakah layer ini diatur lebih lanjut menggunakan kelas yang berbeda? Jika semua panggilan basis data dimasukkan ke dalam satu kelas, tidak ada organisasi. Apakah lebih baik untuk memisahkan ini dengan kelas atau ruang nama yang berbeda?

4. Apakah kelas DAL biasanya statis? Tampaknya rumit untuk membuat instance objek DAL sebelum memanggil salah satu metodenya setiap kali.

Kiat lain untuk melakukan hal-hal dengan cara yang benar dengan lapisan ini akan dihargai.

1. Iya. Dan juga majelis.
2. Saya akan memisahkan dengan lapisan, lalu komponen.
3. Iya. Ada berbagai pendekatan untuk ini, tetapi saya akan memiliki IDatabaseService (abstrak berbagai cara di mana database disebut - ini hampir bisa menjadi pemetaan langsung dari ExecuteScalar / ExecuteNonQuery / ExecuteReader), dan kemudian berbagai kelas akses data yang partisi berdasarkan jenis data. Misalnya, Anda bisa memiliki kelas UserDataAccess yang akan memiliki metode CRUD sederhana yang membuat / memodifikasi / menghapus objek Pengguna. Pendekatan lain adalah dengan memiliki objek Pengguna yang memiliki CRUD built in.

4. Tidak. Itu membuat unit test jauh lebih sulit. Anda harus menggunakan injeksi dependensi untuk meneruskan dependensi ke konstruktor dari setiap kelas akses data (seperti IDatabaseService). Anda kemudian akan meneruskan objek akses data ke objek bisnis, seperti ini:

   BusinessObject businessObject = new BusinessObject (DataAccessObject baru (DatabaseService baru ())); businessObject.PerformOperation ();

Setiap objek bisnis mungkin memerlukan beberapa objek akses data. Kode GUI Anda juga akan menggunakan satu atau beberapa objek bisnis. Beberapa objek bisnis mungkin tidak memerlukan objek akses data apa pun tetapi tidak boleh menggunakan IDatabaseService secara langsung.

Untuk pertanyaan 1 dan 2 ikuti jawaban Matius.

Saya telah menghabiskan banyak waktu untuk mencari tahu cara terbaik untuk menyusun DAL aplikasi desktop. Dan cara terbaik sangat tergantung pada kebutuhan aplikasi. Dalam salah satu aplikasi saya, saya memiliki kelas DA untuk setiap tabel database, yang mendaftarkan diri dengan kelas DataProvider pusat (yaitu singleton) dan menangani CRUD. Setiap kelas DA kemudian dapat memutuskan apakah ingin men-cache semua data tabel dalam RAM atau tidak (kinerja!) Dan / atau apakah itu perlu memiliki kemampuan untuk memicu pembaruan klien otomatis di klien lain yang berjalan di komputer lain (pikirkan multi-pengguna konkurensi). Ini membuatnya sangat mudah untuk menambahkan kelas DAL baru, karena yang harus mereka lakukan hanyalah menyesuaikan dengan antarmuka registrasi.

Tidak setiap DAL membutuhkan fungsionalitas seperti ini, tetapi saya mengetahui bahwa pendekatan itu sendiri (yaitu penyedia data tunggal dan kelas DAL sederhana dengan pendaftaran statis) membuat hidup saya jauh lebih mudah ketika saya mulai menambahkan kelas baru.

Saya pasti tidak akan merekomendasikan membangun CRUD ke kelas tingkat yang lebih tinggi, kecuali jika ini adalah aplikasi yang sangat sederhana. DAL adalah abstraksi dari penyimpanan data. Jika Anda memutuskan untuk mengubah penyimpanan data Anda di beberapa titik di masa depan (bahkan jika itu hanya menggunakan MySQL, bukan MS SQL), Anda akan sangat berterima kasih untuk itu. Plus: objek BLL harus disusun oleh hubungan logika bisnis mereka. Objek DAL disusun berdasarkan jenis wadah penyimpanan yang diwakilinya. Perbedaannya bisa dramatis.

Apakah TIDAK membuat Anda statis kelas DAL. Apa yang Anda peroleh dalam kecepatan pengkodean Anda akan kehilangan berkali-kali dalam testabilitas dan fleksibilitas.