Konvensi penamaan DAL, BAL, dan Layer UI [ditutup]

Saya mengembangkan Aplikasi Web khas dengan lapisan berikut

1. Lapisan UI (MVC)
2. Lapisan Logika Bisnis (BAL)
3. Lapisan Akses Data (DAL)

Setiap layer memiliki objek DTO sendiri termasuk BAL dan DAL. Pertanyaan saya tentang ini adalah sebagai berikut

1. DTO dikembalikan oleh DAL hanya dikonversi ke DTO yang sesuai di BAL dan dikirim ke Layer UI. Atribut dan struktur objek DTO keduanya sama dalam beberapa kasus. Dalam skenario seperti itu, lebih baik mengembalikan DTO di DAL ke lapisan UI tanpa menyertakan objek perantara.

2. Apa cara terbaik untuk memberi nama objek DTO ini dan objek lain di setiap lapisan. Haruskah saya menggunakan beberapa awalan seperti DTOName, ServiceName? Alasan mengapa saya meminta untuk menggunakan awalan adalah karena jika tidak kelas-kelas dalam Solusi saya bentrok dengan kelas-kelas lain dalam Kerangka dan dengan awalan lebih mudah bagi saya untuk memahami di mana masing-masing kelas berada?

Kata pengantar

Semoga ini jelas, tetapi ... dalam ruang nama yang disarankan di bawah ini, Anda akan mengganti MyCompanydan MyProjectdengan nama sebenarnya dari perusahaan dan proyek Anda.

DTO

Saya akan merekomendasikan menggunakan kelas DTO yang sama di semua lapisan. Lebih sedikit poin perawatan seperti itu. Saya biasanya menempatkan mereka di bawah MyCompany.MyProject.Modelsnamespace, dalam proyek VS mereka sendiri dengan nama yang sama. Dan saya biasanya memberi nama mereka hanya setelah entitas dunia nyata yang mereka wakili. (Idealnya, tabel database menggunakan nama yang sama juga, tetapi kadang-kadang masuk akal untuk mengatur skema sedikit berbeda di sana.)

Contoh: Person, Address,Product

Dependensi: Tidak ada (selain pustaka .NET atau helper)

DAL

Preferensi pribadi saya di sini adalah menggunakan satu-untuk-satu set kelas DAL yang cocok dengan kelas DTO, tetapi dalam MyCompany.MyProject.DataAccessnamespace / proyek. Nama kelas di sini diakhiri dengan Enginesufiks untuk menghindari konflik. (Jika Anda tidak menyukai istilah itu, maka DataAccesssufiks juga akan berfungsi dengan baik. Konsisten dengan apa pun yang Anda pilih.) Setiap kelas menyediakan opsi CRUD sederhana yang menyentuh database, menggunakan kelas DTO untuk sebagian besar parameter input dan mengembalikan tipe (di dalam generik Listketika ada lebih dari satu, misalnya, pengembalian dari suatu Find()metode).

Contoh: PersonEngine, AddressEngine,ProductEngine

Ketergantungan: MyCompany.MyProject.Models

BAL / BLL

Juga pemetaan satu-untuk-satu di sini, tetapi dalam MyCompany.MyProject.Logicnamespace / proyek, dan dengan kelas mendapatkan Logicakhiran. Ini harus menjadi satu - satunya lapisan yang memanggil DAL! Kelas-kelas di sini sering kali hanya merupakan lulus sederhana ke DAL, tetapi jika & ketika aturan bisnis perlu diimplementasikan, ini adalah tempatnya.

Contoh: PersonLogic, AddressLogic,ProductLogic

Dependensi: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

Jika ada lapisan API layanan web, saya menggunakan pendekatan satu-untuk-satu, tetapi dalam MyCompany.MyProject.WebApinamespace / proyek, dengan Servicessebagai akhiran kelas. (Kecuali jika Anda menggunakan ASP.NET Web API, dalam hal ini Anda tentu saja akan menggunakan Controllerakhiran sebagai gantinya).

Contoh: PersonServices, AddressServices,ProductServices

Dependensi: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(tidak pernah memotong ini dengan memanggil DAL langsung!)

Pengamatan pada Logika Bisnis

Tampaknya menjadi semakin umum bagi orang untuk meninggalkan BAL / BLL, dan sebagai gantinya menerapkan logika bisnis di satu atau lebih lapisan lain, di mana pun hal itu paling masuk akal. Jika Anda melakukan ini, cukup yakinlah bahwa (1) semua kode aplikasi melewati lapisan dengan logika bisnis, dan (2) jelas dan / atau didokumentasikan dengan baik di mana setiap aturan bisnis tertentu telah diterapkan. Jika ragu, jangan coba ini di rumah.

Catatan Akhir tentang Arsitektur Tingkat Perusahaan

Jika Anda berada di perusahaan besar, atau situasi lain di mana tabel database yang sama dibagikan di beberapa aplikasi, maka saya akan merekomendasikan untuk tidak memasukkan MyProjectbagian dari ruang nama / proyek di atas. Dengan cara itu lapisan-lapisan itu dapat dibagi oleh beberapa aplikasi front-end (dan juga utilitas di belakang layar seperti Layanan Windows). Tetapi lakukan ini hanya jika Anda memiliki komunikasi lintas tim yang kuat dan pengujian kemunduran otomatis menyeluruh yang dilakukan !!! Jika tidak, perubahan satu tim ke komponen inti bersama cenderung merusak aplikasi tim lain.

Saya biasanya membangun aplikasi sebagai

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

Ini agak mirip dengan Sharp-Lite .

Tentang awalan, aku benci mereka. Pedoman Pengodean Internal Microsoft juga membenci mereka. Juga ada alat yang disebut StyleCop yang mengeluhkan awalan juga.