Organizacja GUI, BLL, DAL w projekcie

9

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.

sooprise
źródło

Odpowiedzi:

8
  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.

Matthew Rodatus
źródło
Więc businessObject.PerformOperation () wyglądałby mniej więcej tak: DataAccessObject.PerformOperation (), ponieważ instancja DataAccessObject żyje w businessObject?
sooprise
1
Dziękujemy również za wskazówkę dotyczącą wstrzyknięcia zależności. To dla mnie nowa koncepcja i wydaje się mieć sens. Będę musiał dowiedzieć się więcej na ten temat :)
sooprise
@ sooprise Right - Twoje obiekty biznesowe powinny działać na obiektach dostępu do danych, które działają jako członkowie prywatni. Cieszę się, że doceniasz wskazówkę dotyczącą wstrzykiwania zależności. Jest to kluczowa koncepcja umożliwiająca konserwację i testowanie oprogramowania. Nie ma za co!
Matthew Rodatus,
2

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.

wolfgangsz
źródło
Masz rację, że konkretny projekt wynika z potrzeb aplikacji. Jednak, chyba że źle zrozumiem twój projekt, nie zgadzam się na temat używania singletonów. Może mógłbyś bardziej wyjaśnić swoje podejście. Dlaczego singletony są złe: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
Matthew Rodatus
Przykro mi, ale nie zgadzam się w sprawie singletonów. Są bardzo dobre powody, aby z nich korzystać, a wszystkie rzeczy wymienione na tym blogu brzmią jak wymówki od kogoś, kto nie chce zastosować niezbędnej dyscypliny w swoim kodowaniu.
wolfgangsz
Szczegółowe wyjaśnienie mojego podejścia wypełniłoby znacznie więcej niż to, co mogę tu podać w komentarzach. Wyślij mi swój adres email i będę odpowiadać (WolfgangS na manticoreit kropka com)
wolfgangsz