Adlandırma kuralları DAL, BAL ve UI Katmanı [kapalı]

Aşağıdaki katmanlarla tipik bir Web Uygulaması geliştiriyorum

1. UI Katmanı (MVC)
2. İşletme Mantığı Katmanı (BAL)
3. Veri Erişim Katmanı (DAL)

Her katmanın, BAL ve DAL dahil olmak üzere kendi DTO nesnesi vardır. Bununla ilgili sorularım aşağıdaki gibidir

1. DAL tarafından döndürülen DTO, BAL'daki ilgili DTO'ya dönüştürülür ve UI Katmanına gönderilir. DTO nesnelerinin hem nitelikleri hem de yapısı bazı durumlarda aynıdır. Bu tür senaryolarda, DAL'deki DTO'yu ara nesneyi içermeden UI katmanına basitçe döndürmek daha iyi olur.

2. Bu DTO nesnelerini ve her katmandaki diğer nesneleri adlandırmanın en iyi yolu nedir. DTOName, ServiceName gibi bir önek kullanmalı mıyım? Önek kullanmamın nedeninin nedeni, Çözümümdeki sınıfların Çerçeve'deki diğer sınıflarla çakışmaması ve bir önek ile her sınıfın nerede olduğunu anlamamın daha kolay olmasıdır.

önsöz

Umarım bu aşağıda önerilen ad alanlarında, sen yerini alacak ... açıktır, ancak MyCompanyve MyProjectşirketiniz ve projenin asıl adları ile.

DTOs

Aynı DTO sınıflarını tüm katmanlar arasında kullanmanızı tavsiye ederim. Daha az bakım noktası bu şekilde. Onları genellikle MyCompany.MyProject.Modelsaynı isimdeki kendi VS projelerinde bir ad alanının altına koyarım. Ve genellikle onları sadece temsil ettikleri gerçek dünyadaki varlıktan sonra adlandırırım. (İdeal olarak, veritabanı tabloları da aynı adları kullanır, ancak bazen şemayı biraz farklı şekilde ayarlamak mantıklıdır.)

Örnekler: Person, Address,Product

Bağımlılıklar: Yok (standart .NET veya yardımcı kitaplıklar dışında)

DAL

Buradaki kişisel tercihim, DTO sınıflarıyla eşleşen, ancak bir MyCompany.MyProject.DataAccessad / projede bire bir DAL sınıfları kullanmak . Buradaki sınıf isimleri Engineçatışmaları önlemek için bir sonek ile biter . (Bu terimi beğenmezseniz, bir DataAccesssonek de iyi sonuç verir. Seçtiğiniz her şeyle tutarlı olur.) Her bir sınıf, çoğu giriş parametresi ve dönüş tipleri için DTO sınıflarını kullanarak, veritabanına isabet eden basit CRUD seçenekleri sunar (içinde Listbirden fazla olduğunda bir jenerik , örneğin, bir Find()metottan geri dönüş ).

Örnekler: PersonEngine, AddressEngine,ProductEngine

Bağımlılıklar: MyCompany.MyProject.Models

BAL / BLL

Ayrıca burada bire bir eşleştirme, ancak bir MyCompany.MyProject.Logicad / projede ve sınıfların Logicsonek alınması. DAL'yi çağıran tek katman bu olmalı ! Buradaki sınıflar genellikle DAL'ye basit bir geçiş yoludur, ancak iş kurallarının uygulanması gerektiğinde, bunun yeri burasıdır.

Örnekler: PersonLogic, AddressLogic,ProductLogic

Bağımlılıklar: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

Bir web hizmetleri API katmanı varsa, aynı bire bir yaklaşımı kullanırım, ancak bir MyCompany.MyProject.WebApiad / projede, Servicessınıf soneki olarak. (ASP.NET Web API kullanmıyorsanız, bu durumda elbette Controllersonekini kullanın.)

Örnekler: PersonServices, AddressServices,ProductServices

Bağımlılıklar: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(hiçbir zaman bu baypas doğrudan DAL arayarak!)

İş Mantığına İlişkin Bir Gözlem

İnsanların BAL / BLL'yi dışlamaları ve bunun yerine en mantıklı olanı bir veya daha fazla katmana iş mantığı uygulamaları giderek daha yaygın görünmektedir. Bunu yaparsanız, (1) tüm uygulama kodlarının iş mantığına sahip katmanlardan geçtiğinden ve (2) her bir iş kuralının uygulandığı yerlerde açıkça ve / veya iyi belgelenmiş olduğundan kesinlikle emin olun. Şüpheniz varsa, bunu evde denemeyin.

Kurumsal Seviye Mimarisi Üzerine Son Not

Büyük bir şirketseniz veya aynı veritabanı tablolarının birden fazla uygulama arasında paylaşıldığı başka bir durumdaysanız, MyProjectbölümü yukarıdaki ad alanlarından / projelerinden çıkarmanızı öneririm . Bu şekilde, bu katmanlar birden fazla ön uç uygulaması (ve ayrıca Windows Hizmetleri gibi sahne arkası yardımcı programları) tarafından paylaşılabilir. Ancak bunu, güçlü bir takımlar arası iletişiminiz ve yerinde otomatik regresyon testiniz varsa yapın! Aksi halde, bir ekibin paylaşılan bir çekirdek bileşende yaptığı değişiklikler, başka bir ekibin başvurusunu bozabilir.

Genellikle uygulama yapıyorum

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

Sharp-Lite'a biraz benziyor .

Önekler hakkında, onlardan nefret ediyorum. Microsoft'un İç Kodlama Kuralları da onlardan nefret ediyor. Ayrıca ön ekler hakkında da şikayetçi olan StyleCop adlı bir araç var.