BLL to warstwa logiki biznesowej
DAL to warstwa dostępu do danych
Architektura trójpoziomowa ASP.NET (DAL, BLL, UI)
Grafika reprezentuje strukturę trójwarstwową. Web to warstwa USL
Web –> BLL –> Dal
| | |
| V |
+–> model <—+
1. Architektura trójpoziomowa
1. Warstwa prezentacji (USL): Reprezentuje głównie metodę WEB, ale może być również wyrażona jako tryb WINFORM. Jeśli warstwa logiczna jest dość solidna i dobrze ugruntowana, będzie działać idealnie niezależnie od tego, jak warstwa wydajności zostanie zdefiniowana i zmieniona.
2. Warstwa logiki biznesowej (BLL): głównie dla konkretnych problemów, można ją również rozumieć jako działanie warstwy danych oraz logiczne przetwarzanie danych biznesowych. Jeśli warstwa danych jest elementami budulcowymi, to warstwa logiki jest tym elementem.
3. Warstwa dostępu do danych (DAL): Jest to głównie warstwa operacyjna oryginalnych danych (w formie bazy danych, pliku tekstowego lub innej formy przechowywania danych), a nie oryginalnych danych, czyli działania danych, a nie samej bazy danych, a konkretnie warstwy logiki biznesowej lub warstwy prezentacji
Świadczenie usług danych.
2. Szczególne rozróżnienie
1. Warstwa prezentacji: głównie przyjmuje żądania użytkownika i zwraca dane, zapewniając klientowi dostęp do aplikacji.
2. Warstwa logiki biznesowej: głównie odpowiada za działanie warstwy danych, czyli za połączenie niektórych operacji warstwy danych.
3. Warstwa dostępu do danych: To głównie zależy od tego, czy warstwa danych zawiera przetwarzanie logiczne; w rzeczywistości jej funkcje głównie wykonują różne operacje nad plikiem danych i nie muszą martwić się o inne operacje.
3. Podsumowanie
Struktura trójwarstwowa to ścisłe podejście hierarchiczne, to znaczy, warstwa dostępu do danych (DAL) jest dostępna tylko przez warstwę logiki biznesowej (BLL), a warstwę logiki biznesowej tylko dla warstwy prezentacji (USL). Niektóre struktury trójwarstwowe dodają także inne warstwy, takie jak Factory i Model, które są w rzeczywistości rozszerzeniem i aplikacją opartą na tych trzech warstwach.
Prosty program trójwarstwowy zazwyczaj obejmuje kilka projektów modelu webowego DAL BLL, a ich wzajemne odniesienia są następujące
1) WEB odwołuje się do BLL, Model
2) BLL odnosi się do DAL, Model
3) Model odniesień DAL
4) Model nie ma cytowań
Jeśli chodzi o architekturę trójwarstwową, wszyscy wiedzą, że to warstwa wydajności (UI), warstwa logiki biznesowej (BLL) oraz warstwa dostępu do danych (DAL), a istnieje wiele sposobów na podział każdej warstwy. Ale sposób pisania konkretnego kodu i warstwy tych plików jest niejasny. Poniżej znajduje się prosty przykład, który skłoni Cię do praktykowania projektu architektury trójwarstwowej; ten przykład ma tylko jedną funkcję, czyli proste zarządzanie użytkownikami.
Najpierw stwórz puste rozwiązanie i dodaj następujące elementy oraz pliki
1. Dodać ASP.NET projekt aplikacji webowej, nazwać go interfejsem użytkownika i utworzyć nowy plik formularza webowego User.aspx (w tym User.aspx.cs)
2. Dodaj projekt ClassLibrary, nazwij go BLL i utworz nowy plik klasy UserBLL.cs
3. Dodaj projekt ClassLibrary, nazwij go DAL i stwórz nowy plik klasy UserDAL.cs. Dodaj referencję do SQLHelper. (To jest klasa dostępu do danych Microsoftu, albo możesz napisać cały kod dostępu do danych bezpośrednio.) Zazwyczaj używam klasy DataAccessHelper, którą piszę).
4. Dodaj projekt ClassLibrary, nazwij go Model i stwórz nowy plik typu klasy UserModel.cs
5. Dodaj projekt ClassLibrary, nazwij go IDAL i stwórz nowy plik interfejsu IUserDAL.cs
6. Dodaj projekt ClassLibrary i nazwij go ClassFactory
Wierzę, że widziałeś, że to nie różni się od przykładu z Petshop, a jest prostsze, bo ja też uczę się architektury trójwarstwowej właśnie w Petshopie. Jednak niektórzy przyjaciele mogą być niejasni co do poziomu tych projektów i relacji między nimi, oto wyjaśnienie ich jeden po drugim:
1. User.aspx i User.aspx.cs
Oba dokumenty (oraz elementy, do których należy plik, jak również poniżej, nie będą powtarzane) są częścią warstwy prezentacji. User.aspx łatwiej zrozumieć, ponieważ jest to strona wyświetlana. User.aspx.cs niektórzy uważają, że nie powinno się tego liczyć, lecz do warstwy logiki biznesowej. Jeśli nie robisz warstwowania, nie ma problemu z tym, by User.aspx.cs zarządzać logiką biznesową, a nawet obsługiwać bazę danych, ale jeśli stosujesz warstwowanie, nie powinno się tego robić. W hierarchicznej strukturze User.aspx.cs powinien zajmować się wyłącznie treściami związanymi z wyświetlaniem i nic innego nie powinno być objęte tematem.
Na przykład, jeśli implementujemy funkcję wyświetlania użytkowników w formie listy, to wyciąganie informacji wykonuje BLL, a po wywoływaniu przez interfejs użytkownika (w tym przypadku jest to User.aspx.cs) wywoła BLL, aby uzyskać UserInfo, jest on powiązany z kontrolą danych User.aspx poprzez kod, aby zrealizować wyświetlanie listy. W tym procesie, User.aspx.cs nie odgrywa roli w interfejsie użytkownika, służy jedynie do przekazywania danych, a ponieważ większość faktycznego kodu jest tak zaimplementowana, niektórzy uważają, że nie powinno User.aspx.cs być liczone jako UI, lecz powinno być scalone z BLL do przetwarzania logicznego. Patrząc dalej, wprowadzono nowy wymóg dodania ikony przed każdym użytkownikiem, która wyraźnie odzwierciedla jego płeć, a dla osób poniżej 18 roku życia była ona reprezentowana przez ikonę dziecka. Realizacja tego wymogu to przełom User.aspx.cs, a w tym przypadku User.aspx.cs ma ono realne zastosowanie.
2、NewBLL.cs
Dodaj następujące metody:
public IList GetUsers(): Zwraca listę wszystkich informacji o użytkowniku
public UserInfo GetUser(int UserId): Zwraca dane o wybranym użytkowniku
public bool AddUser(UserInfo User): Dodano informacje o użytkowniku
public bool ChangeUser(UserInfo User): Aktualizuje informacje o użytkowniku
public void RemoveUser(int UserId): Usuwa informacje użytkownika
Ten plik należy do warstwy logiki biznesowej i jest dedykowany do obsługi operacji związanych z logiką biznesową. Wiele osób może myśleć, że jedynym zastosowaniem tej warstwy jest przekazywanie danych z warstwy wydajności na warstwę danych. Rzeczywiście istnieje wiele takich przypadków, ale może to oznaczać jedynie, że projekt jest stosunkowo prosty lub że relacja między samym projektem a biznesem nie jest ściśle zintegrowana (jak obecnie popularny MIS), więc warstwa biznesowa nie ma nic do roboty i pełni jedynie rolę przekazywania. Ale to nie oznacza, że warstwa biznesowa jest zbędna – wraz z rozwojem projektu lub pojawieniem się kolejnych relacji biznesowych warstwa biznesowa odzwierciedli swoją rolę.
Najprawdopodobniejszym błędem jest przypisanie kodu operacji danych do warstwy logiki biznesowej, a bazy danych jako warstwy dostępu do danych.
Na przykład niektórzy znajomi uważają, że warstwa BLL nie ma znaczenia, ale po prostu przesyłają dane DAL i przekazują je do interfejsu bez żadnego przetwarzania. Spójrz na ten przykład
Warstwa BLL
SelectUser(UserInfo userInfo) pobiera dane użytkownika na podstawie nazwy użytkownika lub e-maila, który przychodzi.
IsExist(UserInfoInfo) określa, czy istnieje podana nazwa użytkownika lub e-mail.
Następnie DAL dostarcza również odpowiadającą metodę dla wywołania BLL
SelectUser(UserInfo)
IsExist(UserInfoUserInfo)
W ten sposób BLL pełni wyłącznie rolę transmisyjnego.
Ale jeśli tak:
BLL. IsExist(informacje o użytkowniku)
{
UerInfo user = DAL. SelectUser(User);
return (userInfo.Id != null);
}
W takim razie DAL nie musi implementować metody IsExist(), a w BLL istnieje kod logicznego przetwarzania.
3、UserModel.cs
Byt, to coś, możesz myśleć, że nie jest łatwo podzielić na straty. Razem ze mną, zrozumiałem to tak: UI?àModel?àBLL?àModel?àDAL, więc uważa się, że Model działa jako most do przesyłania danych między warstwami. Ale tutaj nie myślimy o prostych rzeczach, lecz o złożoności.
Czym jest model? To nic takiego! Jest zbędny w architekturze trójpoziomowej. To właściwie najprostsza rzecz w programowaniu obiektowym: klasy. Tabela to klasa, news to także klasa, int, string, doublie itd. to też klasy, to po prostu klasa.
W ten sposób pozycja modelu w architekturze trójwarstwowej jest taka sama jak status zmiennych takich jak int i string, i nie ma innego zastosowania, służy jedynie do przechowywania danych, ale przechowuje złożone dane. Dlatego jeśli obiekty w Twoim projekcie są bardzo proste, możesz bezpośrednio przekazać wiele parametrów bez modelu, tworząc architekturę trójwarstwową.
Dlaczego więc potrzebujesz modelu i jakie są jego zalety? Następujące, co przychodzi na myśl, gdy myślę o pytaniu, wstawione tutaj:
Czy Model może odgrywać większą rolę w przekazywaniu parametrów na każdej warstwie?
Podczas przekazywania parametrów między warstwami możesz wykonać następujące czynności:
AddUser(userId,userName,userPassword,...,)
Może też wyglądać tak:
AddUser(userInfo)
Która z tych dwóch metod jest lepsza? Na pierwszy rzut oka musi być to drugi, znacznie lepszy.
Kiedy przekazywać parametry między warstwami o typach zmiennych normalnych (int, string, guid, double), a co przekazać za pomocą Model? Następujące metody:
SelectUser(int UserId)
SelectUserByName (nazwa użytkownika typu string)
SelectUserByName (nazwa użytkownika ciągu ciągu, hasło do łańcucha znaków)
SelectUserByEmail (e-mail typu string)
SelectUserByEmail (ciąg znaków e-mail, hasło do łańcucha)
Można to podsumować następująco:
SelectUser(userId)
SelectUser(user)
Tutaj używamy obiektu modelu użytkownika, aby uwzględnić cztery tryby kombinacji: nazwa użytkownika, hasło i e-mail. UserId można również scalać z user, ale inne BLL w projekcie implementują interfejsy z parametrami id, więc ten element również jest zachowywany.
userInfo jest przekazywane, więc jak sobie z tym poradzić? Musi to być w kolejności kolejności, jest konkretny kod do ustalenia.
Tutaj jest przetwarzana w tej kolejności
Najpierw sprawdź, czy masz zarówno nazwę użytkownika, jak i hasło, potem czy masz zarówno e-mail, jak i hasło, potem czy masz nazwę użytkownika, a na końcu czy masz adres e-mail. Przetwarzane sekwencyjnie.
W ten sposób, jeśli w przyszłości dodana zostanie nowa treść, czyli karta członkowska (numer), nie ma potrzeby zmieniać interfejsu, wystarczy dodać wsparcie dla numeru w kodzie DAL, a następnie na pierwszym planie dodać wydajność i przetwarzanie zawartości karty członkowskiej.
4、UserDAL.cs
public IList SelectUsers(): Zwraca listę wszystkich informacji o użytkowniku
public UserInfo SelectUser(int UserId): Zwraca zaufane informacje o określonym użytkowniku
public bool InsertUser(UserInfo User): Dodano informacje o użytkowniku
public bool UpdateUser(UserInfo User): Aktualizuje informacje o użytkowniku
public void DeleteUser(int UserId): Usuwa informacje użytkownika
Wielu ludzi nie potrafi rozgryźć warstwy dostępu do danych – która część jest uznawana za warstwę dostępu do danych? Niektórzy uważają, że baza danych to warstwa dostępu do danych, co nie jest jasne co do definicji – DAL to warstwa dostępu do danych, a nie warstwa przechowywania danych, więc baza danych nie może być tą warstwą. Rola SQLHelper polega na ograniczeniu powtarzalnego kodowania i poprawie efektywności kodowania, więc jeśli jestem przyzwyczajony do dbania o efektywność lub korzystania z niebazodanowych źródeł danych, mogę odrzucić SQLHelper, część, którą można odrzucać wedle uznania, jak może stać się warstwą architektury trójwarstwowej.
Można go zdefiniować następująco: kod związany z operacjami ze źródłami danych powinien być umieszczony na warstwie dostępu do danych, która należy do warstwy dostępu do danych
5、IUserDAL
Interfejs warstwy dostępu do danych, to kolejna rzecz, która jest zbędna, bo Petshop go łączy z ClassFactory Factory, więc niektóre projekty robią te dwie rzeczy niezależnie od tego, czy muszą wspierać wiele źródeł danych, a inne nawet nie budują ClassFactory, tylko IDAL, a potem "IUserDAL iUserDal = nowy UserDAL(); Nie wiem, co to znaczy. To jest całkowicie tygrys, a nie anty-dog.
Wiele osób ma tu błędne przekonanie, że istnieje taka relacja: BLL?àIDAL?àDAL, myśląc, że IDAL działa jak pomost między BLL a DAL, a BLL nazywa DAL przez IDAL. Ale rzeczywistość jest taka, że nawet jeśli zakodujesz to tak: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Podczas wykonywania "iUserDal.SelectUsers()" to faktycznie wykonywana jest instancja UserDAL, a nie instancja IUserDAL, więc pozycja IDAL na trzeciej warstwie jest powiązana z poziomem DAL.
Dzięki powyższemu wprowadzeniu hierarchia architektury trójpoziomowej została zasadniczo wyjaśniona. W rzeczywistości mam sposób, by ocenić, czy architektura trójwarstwowa jest standardowa, czyli całkowite zastąpienie którejkolwiek z tych warstw nie wpłynie na pozostałe dwie warstwy, a taka struktura zasadniczo spełnia standard trójwarstwowy (choć jest trudniejsza ^_^ do wdrożenia). Na przykład, jeśli zmienisz projekt z B/S na C/S (lub odwrotnie), to BLL i DAL nie muszą być zmieniane, poza UI; Albo zmień SQLServer na Oracle, po prostu zamień SQLServerDAL na OracleDAL, nie są wymagane żadne inne operacje itd. Początkowo chciałem dodać do artykułu konkretny kod, ale nie uważam, że jest to konieczne, jeśli uznasz to za konieczne, dodam go.
Podsumowanie: Nie myśl, że warstwa jest zbędna tylko dlatego, że jest dla ciebie bezużyteczna, jest szczególnie prosta do wdrożenia, porzucić ją lub użyć do innych celów. Dopóki warstwy są wykonywane, niezależnie od liczby warstw, każda warstwa musi mieć jasny cel i realizację funkcji, nie powinna być wpływana przez rzeczywisty proces, co skutkuje umieszczeniem tego samego typu pliku w różnych warstwach. Nie pozwól, by ta sama warstwa realizowała różne funkcje. |
Opublikowano 07.05.2015 10:53:35
|
|
|
