BLL adalah Lapisan Logika Bisnis
DAL adalah Lapisan Akses Data
Arsitektur tiga tingkat ASP.NET (DAL, BLL, UI)
Grafik mewakili struktur tiga lapis. Web adalah lapisan USL
web –> bll –> dal
| | |
| V |
+–> model <—+
1. Arsitektur tiga tingkat
1. Lapisan presentasi (USL): Ini terutama mewakili metode WEB, tetapi juga dapat dinyatakan sebagai mode WINFORM. Jika lapisan logika cukup kuat dan mapan, itu akan berfungsi dengan sempurna tidak peduli bagaimana lapisan kinerja didefinisikan dan diubah.
2. Lapisan logika bisnis (BLL): terutama untuk masalah tertentu, juga dapat dipahami sebagai pengoperasian lapisan data dan pemrosesan logis bisnis data. Jika lapisan data adalah blok bangunan, maka lapisan logika adalah blok bangunan.
3. Lapisan akses data (DAL): Ini terutama lapisan operasi data asli (dalam bentuk database atau file teks atau bentuk penyimpanan data lainnya), bukan data asli, yaitu pengoperasian data, bukan database, khususnya lapisan logika bisnis atau lapisan presentasi
Penyediaan layanan data.
2. Perbedaan khusus
1. Lapisan presentasi: terutama menerima permintaan pengguna, dan mengembalikan data, memberi klien akses ke aplikasi.
2. Lapisan logika bisnis: terutama bertanggung jawab atas pengoperasian lapisan data, yaitu kombinasi dari beberapa operasi lapisan data.
3. Lapisan akses data: Ini terutama tergantung pada apakah lapisan data Anda berisi pemrosesan logis, pada kenyataannya, fungsinya terutama menyelesaikan berbagai operasi pada file data, dan tidak perlu khawatir tentang operasi lain.
3. Ringkasan
Struktur tiga lapis adalah pendekatan hierarkis yang ketat, yaitu lapisan akses data (DAL) hanya dapat diakses oleh lapisan logika bisnis (BLL), dan lapisan logika bisnis hanya dapat diakses oleh lapisan presentasi (USL). Beberapa struktur tiga lapis juga menambahkan lapisan lain seperti Factory dan Model, yang sebenarnya merupakan ekstensi dan aplikasi berdasarkan ketiga lapisan ini.
Program tiga lapis sederhana umumnya mencakup beberapa proyek Model DAL BLL WEB, dan referensi timbal balik mereka adalah sebagai berikut
1) WEB referensi BLL, Model
2) Referensi BLL DAL, Model
3) Model referensi DAL
4) Model tidak memiliki kutipan
Ketika datang ke arsitektur tiga tingkat, semua orang tahu bahwa itu adalah lapisan kinerja (UI), lapisan logika bisnis (BLL) dan lapisan akses data (DAL), dan ada banyak cara untuk membagi setiap lapisan. Tetapi cara menulis kode spesifik dan lapisan mana file tersebut dihitung tidak jelas. Berikut ini adalah contoh sederhana untuk mengarahkan Anda mempraktikkan proyek arsitektur tiga lapis, contoh ini hanya memiliki satu fungsi, yaitu manajemen pengguna yang sederhana.
Pertama, buat solusi kosong dan tambahkan item dan file berikut
1. Tambahkan proyek Aplikasi Web ASP.NET, beri nama UI, dan buat file Formulir Web baru User.aspx (termasuk User.aspx.cs)
2. Tambahkan proyek ClassLibrary, beri nama BLL, dan buat file Class baru UserBLL.cs
3. Tambahkan proyek ClassLibrary, beri nama DAL, dan buat file Class baru UserDAL.cs. Tambahkan referensi SQLHelper. (Ini adalah kelas akses data Microsoft, atau Anda dapat menulis semua kode akses data secara langsung.) Saya biasanya menggunakan kelas DataAccessHelper yang saya tulis).
4. Tambahkan proyek ClassLibrary, beri nama Model, dan buat file jenis Kelas baru UserModel.cs
5. Tambahkan proyek ClassLibrary, beri nama IDAL, dan buat file Antarmuka baru IUserDAL.cs
6. Tambahkan proyek ClassLibrary dan beri nama ClassFactory
Saya yakin Anda telah melihat bahwa ini tidak berbeda dengan contoh Petshop, dan lebih sederhana, karena saya juga mempelajari arsitektur tiga lapis melalui Petshop. Namun, beberapa teman mungkin tidak jelas tentang tingkat proyek ini dan hubungan di antara mereka, berikut penjelasannya satu per satu:
1. User.aspx dan User.aspx.cs
Kedua dokumen (dan item tempat file berkas, serta di bawahnya, tidak akan diulang) adalah bagian dari lapisan presentasi. User.aspx lebih mudah dipahami karena merupakan halaman tampilan. User.aspx.cs beberapa orang berpikir bahwa itu tidak boleh dihitung, tetapi harus dimasukkan ke dalam lapisan logika bisnis. Jika Anda tidak melakukan layering, maka tidak ada masalah untuk membiarkan User.aspx.cs menangani logika bisnis dan bahkan mengoperasikan database, tetapi jika Anda melakukan layering, ini tidak boleh dilakukan. Dalam struktur hierarkis, User.aspx.cs hanya boleh berurusan dengan konten yang terkait dengan tampilan, dan tidak ada hal lain yang harus dibahas.
Misalnya, jika kita mengimplementasikan fungsi menampilkan pengguna dalam bentuk daftar, maka pekerjaan mengekstraksi informasi dilakukan oleh BLL, dan setelah UI (dalam hal ini User.aspx.cs) memanggil BLL untuk mendapatkan UserInfo, itu terikat ke kontrol data User.aspx melalui kode untuk mewujudkan tampilan daftar. Dalam proses ini User.aspx.cs tidak berperan dalam UI, hanya digunakan untuk meneruskan data, dan karena sebagian besar pengkodean aktual diimplementasikan seperti ini, beberapa orang merasa bahwa User.aspx.cs tidak boleh dihitung sebagai UI, tetapi harus digabungkan ke dalam BLL untuk pemrosesan logis. Melihat lebih jauh, persyaratan baru diajukan untuk menambahkan ikon di depan setiap pengguna untuk mewakili jenis kelamin pengguna dengan jelas, dan bagi mereka yang berusia di bawah 18 tahun, ikon tersebut diwakili oleh ikon anak. Realisasi persyaratan ini adalah giliran User.aspx.cs, dan dalam hal ini User.aspx.cs memiliki kegunaan nyata.
2 、NewBLL.cs
Tambahkan metode berikut:
public IList GetUsers(): Mengembalikan daftar semua informasi pengguna
public UserInfo GetUser(int UserId): Mengembalikan detail pengguna yang ditentukan
public bool AddUser(UserInfo User): Menambahkan informasi pengguna
public bool ChangeUser(UserInfo User): Memperbarui informasi pengguna
public void RemoveUser(int UserId): Menghapus informasi pengguna
File ini termasuk dalam lapisan logika bisnis dan didedikasikan untuk menangani operasi yang terkait dengan logika bisnis. Banyak orang mungkin berpikir bahwa satu-satunya kegunaan lapisan ini adalah untuk meneruskan data dari lapisan kinerja ke lapisan data. Memang ada banyak kasus seperti itu, tetapi ini hanya bisa berarti bahwa proyek tersebut relatif sederhana, atau hubungan antara proyek itu sendiri dan bisnis tidak terintegrasi erat (seperti MIS populer saat ini), sehingga lapisan bisnis tidak ada hubungannya, dan hanya memainkan peran penerusan. Tetapi ini tidak berarti bahwa lapisan bisnis dapat dibuang, seiring bertambahnya proyek, atau ada lebih banyak hubungan bisnis, lapisan bisnis akan mencerminkan perannya.
Kesalahan yang paling mungkin terjadi di sini adalah menetapkan kode operasi data ke lapisan logika bisnis dan database sebagai lapisan akses data.
Misalnya, beberapa teman merasa bahwa lapisan BLL tidak berarti, tetapi mereka hanya mengunggah data DAL dan meneruskannya ke UI tanpa pemrosesan apa pun. Lihatlah contoh ini
Lapisan BLL
SelectUser(UserInfo userInfo) mendapatkan detail pengguna berdasarkan nama pengguna atau email yang masuk.
IsExist(UserInfo userInfo) menentukan apakah nama pengguna atau email yang ditentukan ada.
Kemudian DAL juga menyediakan metode yang sesuai untuk panggilan BLL
PilihPengguna(InfoPenggunaInfoPengguna)
IsExist(UserInfo userInfo)
Dengan cara ini, BLL hanya memainkan peran transmisi.
Tetapi jika Anda melakukannya:
BLL. IsExist(Info pengguna Userinfo)
{
Pengguna UerInfo = DAL. PilihPengguna(Pengguna);
return (userInfo.Id != null);
}
Maka DAL tidak perlu mengimplementasikan metode IsExist(), dan ada kode pemrosesan logis di BLL.
3、UserModel.cs
Entitas, hal ini, Anda mungkin berpikir tidak mudah untuk berstrata. Termasuk saya, saya memahaminya seperti ini: UI?àModel?àBLL?àModel?àDAL, jadi diyakini bahwa Model bertindak sebagai jembatan untuk transmisi data antar lapisan. Tapi di sini, kita tidak memikirkan hal-hal yang sederhana, tetapi tentang kompleksitas.
Apa itu Model? Bukan apa-apa! Ini dapat dibuang dalam arsitektur tiga tingkat. Ini sebenarnya hal paling mendasar dalam pemrograman berorientasi objek: kelas. Tabel adalah kelas, berita juga kelas, int, string, ganda, dll. juga kelas, itu hanya kelas.
Dengan cara ini, posisi model dalam arsitektur tiga lapis sama dengan status variabel seperti int dan string, dan tidak memiliki tujuan lain, hanya digunakan untuk penyimpanan data, tetapi menyimpan data yang kompleks. Oleh karena itu, jika objek dalam proyek Anda sangat sederhana, maka Anda dapat langsung meneruskan beberapa parameter tanpa model untuk membuat arsitektur tiga lapis.
Jadi mengapa Anda membutuhkan model, dan apa manfaatnya? Berikut ini adalah apa yang terlintas dalam pikiran ketika memikirkan sebuah pertanyaan, disisipkan di sini:
Bisakah Model memainkan peran yang lebih besar dalam melewati parameter di setiap lapisan?
Saat meneruskan parameter antar lapisan, Anda dapat melakukan hal berikut:
AddUser(userId,userName,userPassword,...,)
Bisa juga seperti ini:
AddUser(userInfo)
Manakah dari dua metode ini yang lebih baik? Sekilas, itu pasti yang kedua jauh lebih baik.
Kapan meneruskan parameter antar lapisan dengan jenis variabel normal (int, string, guid, double), dan apa yang harus diteruskan dengan Model? Metode berikut:
SelectUser(int UserId)
SelectUserByName(nama pengguna string)
SelectUserByName(nama pengguna string, kata sandi string)
PilihUserByEmail(email string)
PilihUserByEmail(email string, kata sandi string)
Ini dapat diringkas sebagai:
PilihPengguna(userId)
PilihPengguna(pengguna)
Di sini kita menggunakan objek model pengguna untuk menyertakan empat mode kombinasi nama pengguna, kata sandi, dan email. UserId juga dapat digabungkan ke dalam user, tetapi BLL lain dalam proyek mengimplementasikan antarmuka dengan parameter id, sehingga item ini juga dipertahankan.
userInfo diteruskan, jadi bagaimana menghadapinya, ini harus dalam urutan urutan, ada kode khusus untuk diputuskan.
Di sini diproses dalam urutan ini
Pertama, lihat apakah Anda memiliki nama pengguna dan kata sandi, lalu lihat apakah Anda memiliki email dan kata sandi, lalu lihat apakah Anda memiliki nama pengguna, dan kemudian lihat apakah Anda memiliki email. Diproses secara berurutan.
Dengan cara ini, jika konten baru ditambahkan di masa mendatang, kartu keanggotaan (nomor), tidak perlu mengubah antarmuka, cukup tambahkan dukungan untuk nomor dalam kode DAL, lalu tambahkan kinerja dan pemrosesan konten kartu keanggotaan di latar depan.
4、UserDAL.cs
publik IList SelectUsers(): Mengembalikan daftar semua informasi pengguna
public UserInfo SelectUser(int UserId): Mengembalikan informasi tepercaya dari pengguna yang ditentukan
public bool InsertUser(UserInfo User): Menambahkan informasi pengguna
public bool UpdateUser(UserInfo User): Memperbarui informasi pengguna
public void DeleteUser(int UserId): Menghapus informasi pengguna
Yang paling tidak bisa dipahami banyak orang adalah lapisan akses data, bagian mana yang dianggap sebagai lapisan akses data? Beberapa orang berpikir bahwa database adalah lapisan akses data, yang tidak jelas tentang definisinya, DAL adalah lapisan akses data daripada lapisan penyimpanan data, sehingga database tidak bisa berupa lapisan ini. Peran SQLHelper adalah untuk mengurangi pengkodean berulang dan meningkatkan efisiensi pengkodean, jadi jika saya terbiasa peduli dengan efisiensi atau menggunakan sumber data non-database, saya dapat membuang SQLHelper, bagian yang dapat dibuang sesuka hati, bagaimana bisa menjadi lapisan arsitektur tiga lapis.
Ini dapat didefinisikan sebagai berikut: kode yang terkait dengan operasi sumber data harus ditempatkan di lapisan akses data, yang termasuk dalam lapisan akses data
5 、 IUserDAL
Antarmuka lapisan akses data, ini adalah hal lain yang dapat dibuang, karena Petshop membawanya dan pabrik ClassFactory bersamanya, jadi beberapa proyek melakukan dua hal ini terlepas dari apakah mereka perlu mendukung beberapa sumber data atau tidak, dan beberapa bahkan tidak membangun ClassFactory tetapi hanya membangun IDAL, dan kemudian "IUserDAL iUserDal = UserDAL baru(); Saya tidak tahu apa artinya. Ini benar-benar harimau dan bukan anti-anjing.
Banyak orang memiliki kesalahpahaman di sini, yaitu, bahwa ada hubungan seperti itu: BLL?àIDAL?àDAL, berpikir bahwa IDAL bertindak sebagai jembatan antara BLL dan DAL, dan BLL menyebut DAL melalui IDAL. Tetapi kenyataannya adalah bahwa bahkan jika Anda mengkodekannya dengan cara ini: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Saat mengeksekusi "iUserDal.SelectUsers()", sebenarnya instance UserDAL yang dieksekusi, bukan instance IUserDAL, sehingga posisi IDAL di layer ketiga terkait dengan level DAL.
Melalui pengantar di atas, hierarki arsitektur tiga tingkat pada dasarnya dijelaskan. Faktanya, saya memiliki cara untuk menilai apakah arsitektur tiga lapis adalah standar, yaitu, mengganti salah satu dari tiga lapisan sepenuhnya tidak akan mempengaruhi dua lapisan lainnya, dan struktur seperti itu pada dasarnya memenuhi standar tiga lapisan (meskipun lebih sulit ^_^ untuk diterapkan). Misalnya, jika Anda mengubah proyek dari B/S ke C/S (atau sebaliknya), maka BLL dan DAL tidak perlu diubah kecuali untuk UI; Atau ubah SQLServer ke Oracle, cukup ganti SQLServerDAL ke OracleDAL, tidak ada operasi lain yang diperlukan, dll. Awalnya saya ingin menambahkan beberapa kode khusus ke artikel, tetapi saya merasa itu tidak perlu, jika Anda merasa perlu, saya akan menambahkannya.
Ringkasan: Jangan berpikir bahwa lapisan tidak perlu hanya karena tidak berguna bagi Anda, atau sangat mudah untuk diterapkan, atau ditinggalkan, atau menggunakannya untuk tujuan lain. Selama lapisan dilakukan, tidak peduli berapa banyak lapisan yang ada, setiap lapisan harus memiliki tujuan yang jelas dan realisasi fungsi, dan tidak boleh terpengaruh oleh proses yang sebenarnya, sehingga jenis file yang sama terletak di lapisan yang berbeda. Jangan biarkan lapisan yang sama menerapkan fungsi yang berbeda. |
Diposting pada 07/05/2015 10.53.35
|
|
|
