Organizacja GUI, BLL, DAL w projekcie

Czytam o warstwach aplikacji i chcę użyć tego projektu w moim następnym projekcie (c #, .Net). Parę pytań:

1. Czy separacja warstw odbywa się za pomocą przestrzeni nazw? Project.BLL.Whthing, Project.DAL.Whthing

2. Czy lepiej jest rozdzielić warstwy, następnie komponenty (Project.BLL.Component1), czy komponenty, a następnie warstwy (Project.Component1.BLL)

3. Czy w przypadku mojego DAL warstwa ta jest dalej organizowana przy użyciu różnych klas? Jeśli wszystkie wywołania bazy danych są umieszczone w jednej klasie, nie ma organizacji. Czy lepiej byłoby podzielić je na różne klasy lub przestrzenie nazw?

4. Czy klasy DAL są zazwyczaj statyczne? Wydaje się kłopotliwe tworzenie instancji obiektu DAL przed wywołaniem jednej z jego metod za każdym razem.

Będziemy wdzięczni za wszelkie inne wskazówki dotyczące robienia rzeczy z tymi warstwami we właściwy sposób.

1. Tak. A także zespoły.
2. Rozdzielę według warstw, a następnie komponentów.
3. Tak. Istnieją różne podejścia do tego, ale chciałbym mieć IDatabaseService (wyodrębniając różne sposoby, w których wywoływana jest baza danych - może to być prawie bezpośrednie mapowanie ExecuteScalar / ExecuteNonQuery / ExecuteReader), a następnie różne klasy dostępu do danych, które partycja według rodzaju danych. Na przykład, możesz mieć klasę UserDataAccess, która miałaby proste metody CRUD, które tworzą / modyfikują / usuwają obiekty użytkownika. Innym podejściem byłoby posiadanie obiektu użytkownika z wbudowanym CRUD.

4. Nie. To znacznie utrudnia testowanie jednostkowe. Należy użyć wstrzykiwania zależności, aby przekazać zależności do konstruktora każdej klasy dostępu do danych (np. IDatabaseService). Następnie przekazujesz obiekty dostępu do danych do obiektów biznesowych, w następujący sposób:

   BusinessObject businessObject = new BusinessObject (new DataAccessObject (new DatabaseService ())); businessObject.PerformOperation ();

Każdy obiekt biznesowy może wymagać wielu obiektów dostępu do danych. Twój kod GUI używałby również jednego lub więcej obiektów biznesowych. Niektóre obiekty biznesowe mogą nie potrzebować żadnych obiektów dostępu do danych, ale nigdy nie powinny bezpośrednio korzystać z IDatabaseService.

W przypadku pytań 1 i 2 należy przejść do odpowiedzi Matthew.

Spędziłem dużo czasu, próbując znaleźć najlepszy sposób na uporządkowanie DAL aplikacji komputerowych. A najlepszy sposób naprawdę zależy od potrzeb aplikacji. W jednej z moich aplikacji poszedłem drogą posiadania klasy DA dla każdej tabeli bazy danych, która rejestrowała się w centralnej (tj. Singleton) klasie DataProvider i obsługiwała CRUD. Każda klasa DA może następnie zdecydować, czy chce buforować wszystkie dane tabeli w pamięci RAM, czy nie (wydajność!) I / lub czy musi mieć możliwość wyzwalania automatycznych aktualizacji klienta na innych klientach działających na innych komputerach (pomyśl o wielu użytkownikach konkurencja). Ułatwia to dodawanie nowych klas DAL, ponieważ wystarczy, że będą zgodne z interfejsem rejestracji.

Nie każdy DAL potrzebuje takiej funkcjonalności, ale dowiedziałem się, że samo podejście (tj. Dostawca danych singleton i proste klasy DAL ze statyczną rejestracją) znacznie ułatwiło mi życie, kiedy zacząłem dodawać nowe klasy.

Zdecydowanie nie polecałbym budowania CRUD w klasach wyższego poziomu, chyba że jest to bardzo prosta aplikacja. DAL jest abstrakcją przechowywania danych. Jeśli zdecydujesz się zmienić przechowywanie danych w pewnym momencie w przyszłości (nawet jeśli będzie to tylko używać MySQL zamiast MS SQL), będziesz bardzo za to wdzięczny. Ponadto: obiekty BLL powinny być uporządkowane według relacji logiki biznesowej. Obiekty DAL są uporządkowane według typów kontenerów pamięci, które reprezentują. Różnice mogą być dramatyczne.

Czy NIE dokonać klas DAL statycznych. To, co zyskujesz na szybkości kodowania, wiele razy stracisz na testowalności i elastyczności.