Logika domeny a weryfikacja danych

Question

Jestem zajęty czytaniem i czerpaniem przyjemności z Injection Dependency Injection w sieci .Net Mark Seemann.

Jest mi trudno wytłumaczyć dokładny kontekst, więc proszę tylko zadać sobie to pytanie, jeśli jesteś zaznajomiony z książką.

Moje pytanie dotyczy dwóch klas produktów w rozdziale 2 str. 49. Jest jeden w warstwie Domena i jeden w warstwie dostępu do danych. Wyjaśniono, że klasa produktu w warstwie dostępu do danych została utworzona przez kreator Linq to Entity.

Pracuję z Linq na SQL i mogę przyozdobić moją klasę modelu atrybutami Ling do SQL, więc nie muszę mieć drugiej klasy. Na przykład.

[Table(Name="Customers")] 
public class Customer 
{ 
    [Column(IsPrimaryKey=true)] 
    public string CustomerID; 
    [Column] 
    public string City; 
} 

Jednak czuję, że to jest mieszanie obawy i to w efekcie mocno para mój warstwa domeny do LINQ do warstwy dostępu do danych SQL. Czy zgadzasz się z tym?

Załóżmy, że tworzę dwie klasy "Klientów" dla domeny i warstwy dostępu do danych. Powiedzmy, że miasto jest polem wymaganym. Podczas zapisywania ta reguła musi zostać sprawdzona. Czy powinno to być zrobione w warstwie domeny lub warstwie dostępu do danych, czy też w obu?

Dzięki Daryn

Answer 1

Oczywiście, że pary Twój warstwa domeny DAL. Co gorsza, twoje jednostki warstwy domeny będą miały taką samą strukturę jak tabele w twoim DB. Jeśli te tabele są relacyjne, nie będzie to najlepsza reprezentacja modelu domeny.

Pozwolimy, aby jednostki Linq-SQL istniały w DAL, a następnie mamy klasy odwzorowania w DAL, przekształcają jednostki L2S w podmioty domeny i na odwrót. I to jest w porządku, ponieważ DAL to naprawdę ORM, a jego zadaniem jest wykonanie tego mapowania.

Powiedziałbym, że jeśli miasto jest wymagane, jako reguła biznesowa, jest to logika biznesowa i należy do reguły biznesowej w warstwie logiki biznesowej. Istnieją pakiety walidacji, które mogą pomóc w tym problemie.

Answer 2

Jednak uważam, że jest to mieszanie obaw, a to w efekcie ściśle łączy moją warstwę domeny z warstwą dostępu do danych Linq do SQL. Czy zgadzasz się z tym?

Tak, to by było. Zarówno Entity Framework (pierwszy kod), jak i nhibernate mogą korzystać z oddzielnych klas mapowania, które sprawią, że twoje modele będą czyste bez zależności od OR/M.

Uwaga dodatkowa: Modele domeny nie powinny mieć ustawników publicznych dla właściwości (w DDD). Ponieważ skutecznie przenosi logikę modelu na zewnątrz modelu.

Załóżmy, że tworzę dwie klasy "Klientów" dla domeny i warstwy dostępu do danych. Powiedzmy, że miasto jest polem wymaganym. Podczas zapisywania ta reguła musi zostać sprawdzona. Czy powinno to być zrobione w warstwie domeny lub warstwie dostępu do danych, czy też w obu?

Jednostka bazy danych powinna istnieć tylko w obrębie klas repozytorium i dlatego niekoniecznie musi ją potwierdzać. Model domeny, który jest zapisywany, powinien już mieć poprawny stan.

Przykład:

public class ArticleRepository 
{ 
    public void Save(Article article) 
    { 
     // Article is already in a correct state 
     // (thanks to no public setters) 

     var dbEntity = new ArticleEntity(); 
     Mapper.Map(article, dbEntity); 
     _dbContext.Save(dbEntity); 
    } 
}