iş/hizmet katman tasarımı

Question

Bizim n-katmanlı mimarisi yeniden değerlendirmek çalışıyorum ve deneyimlerinizi dayalı bazı öneriler almak isteriz n-katmanı. İşte bizim tipik .NET n-layer (bazen n-tier) tasarımımız.

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

DataAccess tipik Entity Framework 4 ve Repository sınıfları içerir. Tablo için bir depoya sahip olmaktan kaçınmak için Aggregate Root konseptini takip etmeye çalışıyorum, deneyimimden daha kolay. Depolar ve Tablolar arasında% 70'lik bir eşleşme eğilimi var.

Modeli genellikle benim Entity Framework 4 varlıkları oluşur, ben başarı ile Öz-Takip EF varlıkları kullanıyorum.

İş çoğu ile mücadele budur. Ben genellikle her Repository için Manager sınıf var. Bu sınıf, repository.Add() öğesine yönlendirmeden önce iş doğrulaması gerçekleştirecek .Add() gibi yöntemleri içerir. aslında bir web servisi tabanlı bir çözüm oluşturmak için arıyorum eğer

Hizmetleri, genellikle sadece bu uygulayacak. Bu katman, DTO'lar ve varlıklar arasındaki marshaling istekleri/yanıtları ile görevlendirilecektir. Ve en önemlisi daha fazla coarse grained arayüzü sağlar. Örneğin AccountManager.ValidateCash(), OrderManager.SubmitOrder() da yer alabilir bir ticari işlem için gerçekten facade bir TradingService.SubmitTrade(), vb

İşim tabakası çok varlıktır Endişeler merkezli, gerçekten sadece varlıklar arasında validasyon ile varlıklar ve depo arasındaki yapıştırıcı. Hizmet Katmanının depolara referans teşkil eden (özünde "iş katmanını" atlayan) olduğu birçok tasarım gördüm. Özünde, İş katmanım ile aynı amaca hizmet eder, doğrulama yapar, ancak bunun sorumluluğu (ve isimlendirmesi) daha yüksek, daha kaba taneli bir ticari işlemdir. Yukarıdaki örneği kullanarak TradingService.submitTrade(), herhangi bir işletme yöneticisi sınıfına delege etmeyecektir, kendisi gerekli depoları sorgulayacaktır, tüm doğrulama işlemini gerçekleştirecektir.

Tasarımımı bir işi yeniden kullanabileceğim bir şekilde beğeniyorum Birden çok hizmet çağrısında katman yöntemi, ancak ben her depo için eşleşen bir iş katmanı yöneticisi var, ekstra çalışma tonu yaratıyor olmasından nefret ediyorum. Belki de çözüm, İş Katmanı düzeyinde farklı bir gruplandırmadır? Örneğin, PhoneManager ve EmailManager gibi bireysel Yönetici sınıflarını (Phone varlıkları ve E-posta varlıklarım var) ContactsManager gibi bir mantıksal Yönetici sınıfına birleştirin (not "İletişim" varlık tipim yok). ContactManager.GetPhones() ve ContactManager.GetEmail(), vb. Gibi yöntemlerle, Hizmet katmanına, İş katmanına, her ikisine vb. Sahip olup olmadıklarına bakılmaksızın, diğerlerinin sorumluluklarını nasıl organize edip delege ettiklerini merak ettiğim her şeyden çok daha fazlasını tahmin ediyorum. ORM bağlam referansı, vb. Neyi içerir?

Answer 1

Endişelerinizin sonuna doğru özetlediğiniz şeyleri ve iş katmanı grubundaki şeyleri, iş açısından daha mantıklı bir şekilde yapan yöneticilere yöneliyorum. örneğin

kullanarak İletişim, kesinlikle bir PhoneManager veya EmailManager olmazdı. "ContactsManager" benim için daha kullanışlı bir gruplamadır, aynı şeyi sadece daha az sayıda yönetici ile başa çıkarak gerçekleştirir. İş açısından bakıldığında, telefon numaraları ve e-postalar zaten bir İletişimin küçük parçalarıdır. Sadece kendi tabloları ve varlıkları olduğu için kendi yöneticilerine ihtiyaçları olduğu anlamına gelmez. Bu onları tekrar kullanamayacağınız anlamına gelmez.Çeşitli yerlerde e-posta adresleriyle çalışmanız gerekirse, ContactsManager ilgili yöntemlere sahip olabilir.

Ortamımızda sahip olma eğilimi, bir veri tabanı/varlık katmanı, ardından sunucu üzerinde oturan ve iş kurallarını ve iş mantığını işleyen bir iş katmanıdır. Bu iş katmanı, müşteriye WCF üzerinden bir hizmet olarak (veya en azından müşteriyle ilgili olan şeyler) bir hizmet olarak açığa çıkar.

Ne yapmak istediğinizi zaten biliyormuşsunuz gibi geliyor, bu yüzden üzerinde biraz prototip çalışması yapmayı ve sizin için nasıl çalıştığını görmeyi öneririm. :)