Seperti itu
Selama bertahun-tahun, saya telah mengatur solusi perangkat lunak saya sebagai berikut:
- Data Access Layer (DAL) untuk abstrak bisnis mengakses data
- Business Logic Layer (BLL) untuk menerapkan aturan bisnis ke set data, menangani otentikasi, dll.
- Utilitas (Util) yang hanya merupakan perpustakaan dari metode utilitas umum yang telah saya bangun dari waktu ke waktu.
- Lapisan Presentasi yang tentu saja bisa web, desktop, seluler, apa pun.
Seperti sekarang
Selama empat tahun terakhir ini saya telah menggunakan Microsoft's Entity Framework (saya didominasi oleh .NET dev) dan saya menemukan bahwa memiliki DAL menjadi lebih rumit daripada bersih karena fakta bahwa Entity Framework telah melakukan pekerjaan yang DAL saya dulu lakukan: itu abstrak bisnis menjalankan CRUD terhadap basis data.
Jadi, saya biasanya berakhir dengan DAL yang memiliki kumpulan metode seperti ini:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
Kemudian, di BLL, metode ini digunakan sebagai berikut:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
Ini adalah contoh sederhana tentu saja karena BLL biasanya memiliki beberapa garis logika yang diterapkan, tetapi sepertinya sedikit berlebihan untuk mempertahankan DAL untuk cakupan yang terbatas.
Bukankah lebih baik meninggalkan DAL dan menulis metode BLL saya seperti itu:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
Saya sedang mempertimbangkan untuk membatalkan DAL dari proyek-proyek masa depan karena alasan-alasan yang disebutkan di atas, tetapi sebelum melakukannya, saya ingin memberikan polling kepada masyarakat di sini untuk tinjauan balik / pandangan jauh ke depan Anda sebelum saya memulai proyek dan menemukan masalah yang tidak saya ketahui. t mengantisipasi.
Pikiran apa pun dihargai.
Memperbarui
Tampaknya konsensus bahwa DAL terpisah tidak diperlukan tetapi (membuat kesimpulan saya sendiri di sini) adalah ide yang baik untuk menghindari vendor mengunci. Misalnya, jika saya memiliki DAL yang abstrak panggilan EF seperti yang digambarkan di atas, jika saya pernah beralih ke beberapa vendor lain saya tidak perlu menulis ulang BLL saya. Hanya pertanyaan dasar di DAL yang perlu ditulis ulang. Karena itu, saya merasa sulit membayangkan sebuah skenario di mana ini akan terjadi. Saya sudah dapat membuat model EF dari Oracle db, MSSQL diberikan, saya cukup yakin bahwa MySql juga dimungkinkan (??) jadi saya tidak yakin apakah kode tambahan akan memberikan ROI yang berharga.
GetMyObjects(int myId)lebih mudah daripada mengejek / mematikan / memalsukan GetObjects.Where(ob => op.accountId == myId).ToList().