Rozdzielenie pobierania danych i obiektów biznesowych między warstwami DAL i BLL

Przed opublikowaniem tego pytania przeprowadziłem kilka badań. Wśród innych pytań lub postów jedno z nich znajduje się poniżej. Nie mogłem zrozumieć, jak to ustalić ...

Obiekty biznesowe w warstwie dostępu do danych

Mam repozytorium, a warstwy biznesowe wywołują repozytorium w celu pobrania danych. Powiedzmy, że mam następujące klasy dla BLL i DAL:

class BllCustomer
{
    public int CustomerId {get; set;}
    public String Name {get; set;}
    public BllAddress Address {get; set;}
}

class BllAddress
{
     public int AddressId {get; set;}
     public String Street {get; set;}
     public String City {get; set;}
     public String ZipCode {get; set; }
}

class DalCustomer 
{
    public int CustomerId {get; set;}
    public String Name {get; set;}
    public int AddressID {get; set;}
}

class DalAddress
{
     public int AddressId {get; set;}
     public String Street {get; set;}
     public String City {get; set;}
     public String ZipCode {get; set; }
}

Jeśli BLL chce pobrać obiekt Customer, wywołałby GetCustomerById (customerId) w DAL.

Oto moje obawy, których nie mogłem zrozumieć:

1. Nie widzę, jak ustalić, jaki obiekt powinien zwrócić GetCustomerById w DAL? Czy powinien zwrócić BllCustomer czy DalCustomer?

2. Gdzie powinno być pobierane (i / lub konwertowane na obiekt biznesowy) adresy powiązane z klientem?

Jeśli DAL zwróci obiekty Dal, wówczas logika pobierania i wypełniania adresu może znajdować się tylko w BLL. Jeśli DAL zwraca obiekty BLL, wówczas logika do pobrania i wypełnienia adresu może znajdować się w BLL lub DAL. Obecnie DAL zwraca obiekty biznesowe, a logika do ich wypełnienia znajduje się w DAL.

Z tego, co czytam, wydaje mi się, że nie ma dobra ani zła. Z linku zamieszczonego powyżej są ludzie, którzy mówią w jedną stronę, a inni mówią w drugą stronę. Ale jak ustalić, który z nich najlepiej pasuje do mojej sprawy?

Każda pomoc będzie mile widziana.

Nie widzę, jak ustalić, jaki obiekt powinien zwrócić GetCustomerById w DAL? Czy powinien zwrócić BllCustomer czy DalCustomer?

Powinien zwrócić obiekt DalCustomer , zwrócenie obiektu BllCustomer złamie zasadę pojedynczej odpowiedzialności . Obiekt DalCustomer można wyświetlić jako interfejs lub umowę używane przez warstwę biznesową (lub konsumenta). W efekcie, jeśli zwróci klienta BllCustomer, DAL musiałby obsłużyć każdy obiekt warstwy biznesowej, który go wywołuje lub mógłby go wywołać.

Gdzie powinno być pobierane (i / lub konwertowane na obiekt biznesowy) adresy powiązane z klientem?

Konwersji należy dokonać w modelu widoku lub menedżerze. Musisz mieć pośrednika, aby zadzwonić do usługi lub komponentu dostępu do danych. Jeśli czujesz potrzebę, możesz dokonać konwersji w swoim obiekcie BllCustomer . Ale kiedy zamieniasz DAL z MSSQL na Oracle, na przykład zwracany obiekt (lub interfejs) musi pozostać taki sam.

Najlepiej, aby warstwa biznesowa była również niezależna od warstwy danych. Warstwa biznesowa odpowiada za reguły biznesowe. To tutaj dodasz swoje sprawdzania poprawności za pomocą ram sprawdzania poprawności w celu egzekwowania reguł biznesowych.

Twoje repozytorium powinno zwrócić BLL lub obiekt domeny. istnieje prawdopodobieństwo, że w ogóle nie potrzebujesz obiektu DAL.

public class Customer
{
    public string Name {get; private set;}
    public Customer(string name)
    {
        this.Name = name;
    }
}

public class Repository
{
    public Customer GetCustomer(string id)
    {
        //get data from db
        return new Customer(datarow["name"]);
    }
}

Zazwyczaj DAL nie ma wiedzy na temat BLL. Pomyśl o tym w ten sposób, inna aplikacja z innym BLL mogłaby używać tego samego DAL. Aplikacja / moduł zobowiązań i aplikacja należności dla tej samej firmy dzieliłyby dane (klienci, opłaty, płatności itp.). Próba posiadania jednej biblioteki DLL posiadającej znajomość więcej niż jednej BLL byłaby bardzo trudna i niepotrzebna. Pozwoliłoby to również na zmianę przechowywania danych bez wpływu na BLL (o ile nie zepsujesz interfejsów).

Możesz teraz przekazać obiekt DAL do BLL lub możesz utworzyć trzeci zestaw obiektów: Entity. Zawierają one tylko wartości, które należy przekazać razem. DAL będzie odwoływał się do encji i wchodził w interakcje z twoją pamięcią / bazą danych, a BLL obsługiwałby całą logikę i odnosiłby się do DAL.

class EntCustomer
{
    public int CustomerId {get; set;}
    public String Name {get; set;}
    public BllAddress Address {get; set;}
}
class BllCustomer
{
   //reference EntCustomer, DalCustomer and handle business rules/logic
}

class DalCustomer 
{
   //reference EntCustomer and interact with data storage
}

DAL powinien być niezależny od BL i BL zależny od DAL. Twój interfejs powinien mieć dostęp do danych tylko przez BL. Dobrą praktyką jest zwracanie DataTable lub DataRow z DAL, a następnie Konwertowanie DataTable / DataRow na obiekty BL. Kiedy twój interfejs użytkownika potrzebuje dostępu do danych, może uzyskać dostęp z BL. Interfejs użytkownika będzie więc niezależny od nazwy kolumny i typu bazy danych (SQL Server, Oracle ..). W ten sposób Twój interfejs użytkownika będzie całkowicie niezależny od DAL. Osobiście wolę nazwę klasy jak „CustomerBL”, nie używaj słowa BL na początku nazwy klasy.

Poniżej patrz przykładowy kod.

//Customer Class
class BllCustomer
{
    public int CustomerId { get; set; }
    public String Name { get; set; }
    public BllAddress Address { get; set; }

    public static BllCustomer GetByCustomerId(int id)
    {
        DataRow dr = DalCustomer.GetByCustomerId(id);
        if (dr == null)
            return null;
        BllCustomer oCust = new BllCustomer();
        oCust.CustomerId = int.Parse(dr["CustomerId"].ToString());
        //Do for other class members and load values

        return oCust;
    }
}


class DalCustomer
{

    public static DataRow GetByCustomerId(int id)
    {
        //Get Data row from Database and return Datarow
        DataRow CustomerRow = GETFROMDATABASE("SELECT * from CUSTOMER");
        return CustomerRow;
    }
}