Jakie obiekty powinieneś zwrócić z warstwy dostępu do danych do warstwy biznesowej i systemu klasy N

Question

Jeśli masz na przykład tabelę bazy danych o nazwie Osoba (identyfikator, nazwa itp.), Jakiego rodzaju obiekt powinien zwracać warstwę dostępu do danych do poziomu biznesowego? myślę coś takiego:

//data access tier 
public class DataAccess{ 

    public interface IPerson{ 
     int ID{ get; set; } 
     string Name{ get; set; } 
    } 

    internal class Person : IPerson{ 
     private int id; 
     private string name; 

     public int ID{ get{return id; } set{ id=value; } } 
     public int Name{ get{retutn name; } set{ name=value; } 
    } 

    public static IPerson GetPerson(int personId) 
    { 
     //get person record from db, populate Person object 
     return person; 
    } 
} 

//business tier 
public class Person : IPerson{ 
    private int id; 
    private string name; 

    public int ID{ get{return id;} set{id=value;} } 
    public string Name{ get{return name;} set{name=value;} } 

    public void Populate(int personId){ 
     IPerson temp = DataAccess.GetPerson(personId); 
     this.ID = temp.ID; 
     this.Name = temp.Name; 
    } 
} 

Ale to wszystko wydaje się nieco kłopotliwe? Czy istnieje bardziej eleganckie rozwiązanie tego problemu? Czy zamiast tego powinienem zwrócić obiekt DataRow z warstwy dostępu do danych do warstwy biznesowej?

Answer 1

Nie trzeba powtórzyć definicji klasy w warstwie dostępu do danych (DAL).

Można tworzyć jednostki biznesowe jako "puste" kontenery w oddzielnym zespole, np. Twoja klasa Person może być po prostu: -

public class Person 
{ 
    int ID { get; set: } 
    string Name { get; set: } 
} 

Następnie możesz podać DAL odniesienie do warstwy podmiotów gospodarczych. Obiekty kontrolerów, niezależnie od tego, czy znajdują się w osobnej warstwie logiki biznesowej, czy w warstwie interfejsu użytkownika, mogą po prostu wywołać DAL, który może utworzyć jednostkę biznesową, wypełnić ją z bazy danych i zwrócić do kontrolera.

This article Imar Spaanjaars ma ładne wyjaśnienie tego wzoru.

Answer 2

Twoja warstwa biznesowa zdecydowanie nie chce wiedzieć o wierszach danych - spróbuj pozostawić klasy danych w warstwie danych. Zmniejsza to sprzężenie i umożliwia zmianę warstwy trwałości w późniejszym terminie bez hurtowej ponownej architektury.

Aby rozwiązać konkretny problem, można:

• Tworzenie podstawowych obiektów danych/jednostek w warstwie danych i przekazać je do warstwy biznesowej z przeznaczeniem do spożycia.
• Albo, jak się wydaje, robisz, twórz DTO (obiekty przesyłania danych), które istnieją wyłącznie jako sposób przesyłania danych z warstwy danych do bogatszej implementacji twojego obiektu biznesowego w wyższej warstwie. Możesz to zrobić jako część wzorca repozytorium w modelu bogatej domeny.

Kolejną rzeczą, o której warto pomyśleć, są poziomy warstw v - ma znaczenie, jak myślisz o tych rzeczach. Poziomy są zazwyczaj fizyczne, innymi słowy określają granice między procesami. Warstwy są zasadniczo logiczne, oddzielają funkcję programu na luźno powiązane jednostki. W tym przypadku celujesz w warstwy.

Answer 3

Jeśli utworzysz interfejsy do klas DAO i umieścisz je w warstwie biznesowej, możesz odwoływać się do warstwy biznesowej z warstwy Data Access. Klasy DAO w warstwie danych zwracają obiekty z warstwy biznesowej.

Twoja warstwa biznesowa odwołuje się do interfejsów zamiast bezpośrednio odwoływać się do obiektów dostępu do danych. Wstrzyknięcie zależności przez pojemnik IoC (na przykład Castle Windsor) pozwoli Ci to osiągnąć.

Ta technika nazywa się oddzielić połączony i jest opisany tutaj:

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

Najlepszym wyjaśnieniem tej techniki widziałem można znaleźć w tym artykule na NHibernate najlepszych praktyk, autor Billy McCafferty.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

Wyrób ma dużo informacji, które są specyficzne dla NHiberbate, ale dobre pół z nich jest po prostu solidne informacje na temat projektowania aplikacji należy luźno i łatwo testowane urządzenie.

Answer 4

Zgodnie z tą zasadą, że każda warstwa musi luźno połączyć się z górną warstwą, dodanie odwołania BL do DAL nie jest dobrym pomysłem. Lepiej zdefiniować model danych w DAL za pomocą interfejsu i utworzyć formularz Business Unit w BL. jak moje doświadczenia, lepiej korzystać z repozytorium w DAL i dostępu w swoim Business Entity lub Business Process.