BLL은 비즈니스 로직 계층입니다
DAL은 데이터 액세스 레이어(Data Access Layer)입니다
ASP.NET 의 3단계 아키텍처 (DAL, BLL, UI)
그래픽은 3층 구조를 나타냅니다. 웹은 USL 계층입니다
웹 –> BLL –> DAL
| | |
| V |
+–> 모델 <—+
1. 3단계 아키텍처
1. 프레젠테이션 계층(USL): 주로 웹 방식을 나타내지만 WINFORM 모드로도 표현할 수 있습니다. 논리 계층이 매우 견고하고 잘 구축되어 있다면, 성능 계층이 어떻게 정의되고 변경되든 완벽하게 작동합니다.
2. 비즈니스 로직 계층(BLL): 주로 특정 문제에 대해, 데이터 계층의 작동과 데이터 비즈니스의 논리적 처리로도 이해할 수 있습니다. 데이터 계층이 빌딩 블록이라면, 논리 계층이 빌딩 블록입니다.
3. 데이터 접근 계층(DAL): 주로 원본 데이터(데이터베이스, 텍스트 파일 또는 기타 데이터 저장 형태의 형태)의 연산 계층이며, 원본 데이터, 즉 데이터베이스가 아니라 비즈니스 로직 계층이나 프레젠테이션 계층의 동작을 의미합니다
데이터 서비스 제공.
2. 구별
1. 프레젠테이션 계층: 주로 사용자의 요청을 수락하고 데이터를 반환하여 클라이언트가 애플리케이션에 접근할 수 있도록 합니다.
2. 비즈니스 로직 계층: 주로 데이터 계층의 동작, 즉 일부 데이터 계층 연산의 조합을 담당합니다.
3. 데이터 접근 계층: 데이터 계층이 논리 처리를 포함하는지에 따라 다릅니다. 사실 논리 처리는 주로 데이터 파일에 대한 다양한 연산을 수행하며, 다른 연산에 대해서는 신경 쓰지 않습니다.
3. 요약
3계층 구조는 엄격한 계층적 접근법으로, 데이터 접근 계층(DAL)은 비즈니스 논리 계층(BLL)에서만 접근할 수 있고, 비즈니스 논리 계층은 프레젠테이션 계층(USL)에서만 접근할 수 있습니다. 일부 3계층 구조는 Factory와 Model과 같은 다른 계층도 추가하는데, 이는 이 세 계층을 기반으로 한 확장이자 적용입니다.
간단한 3계층 프로그램은 일반적으로 DAL BLL 웹 모델의 여러 프로젝트를 포함하며, 이들의 상호 참조는 다음과 같습니다
1) WEB 참조 BLL, 모델
2) BLL 참조 DAL, 모델
3) DAL 참조 모델
4) 모델에 인용문이 없습니다
3단계 아키텍처에 관해서는, 모두가 알고 있는 것은 성능 계층(UI), 비즈니스 논리 계층(BLL), 데이터 접근 계층(DAL)이며, 각 계층을 세분화하는 다양한 방법이 있습니다. 하지만 구체적인 코드를 어떻게 작성하고 그 파일들이 어느 계층에 속하는지는 모호합니다. 다음은 3계층 아키텍처 프로젝트를 연습할 수 있도록 안내하는 간단한 예시입니다. 이 예시는 단 하나의 기능, 즉 사용자 관리만을 가지고 있습니다.
먼저, 빈 해답을 만들고 다음 항목과 파일을 추가하세요
1. ASP.NET 웹 애플리케이션 프로젝트를 추가하고 UI로 이름 붙이고, 새로운 웹 폼 파일 User.aspx(User.aspx.cs 포함)를 생성합니다.
2. ClassLibrary 프로젝트를 추가하고 BLL로 이름 붙인 후 새로운 클래스 파일 UserBLL.cs
3. ClassLibrary 프로젝트를 추가하고 DAL로 이름 짓고, 새로운 클래스 파일 UserDAL.cs을 생성합니다. SQLHelper 참조를 추가하세요. (이것은 마이크로소프트의 데이터 액세스 클래스이며, 모든 데이터 액세스 코드를 직접 작성할 수도 있습니다.) 저는 보통 제가 작성한 DataAccessHelper 클래스를 사용합니다).
4. ClassLibrary 프로젝트를 추가하고 Model로 이름을 지은 후 새로운 Class 유형 파일 UserModel.cs
5. ClassLibrary 프로젝트를 추가하고 IDAL로 명명하고 새로운 인터페이스 파일 IUserDAL.cs
6. ClassLibrary 프로젝트를 추가하고 ClassFactory로 이름 붙여
이것이 Petshop의 예시와 다르지 않으며, 저도 Petshop을 통해 3층 아키텍처를 배워서 더 단순하다는 것을 보셨을 겁니다. 하지만 일부 친구들은 이 프로젝트들의 수준과 그 관계에 대해 모호할 수 있으니, 여기 하나하나 설명해 드리겠습니다:
1. User.aspx와 User.aspx.cs
두 문서(그리고 파일이 속한 항목 및 아래는 반복되지 않습니다)는 프레젠테이션 계층의 일부입니다. User.aspx 디스플레이 페이지라서 이해하기 쉽습니다. User.aspx.cs 일부 사람들은 이를 집계하지 말고 비즈니스 로직 계층에 포함시켜야 한다고 생각합니다. 레이어링을 하지 않는다면 비즈니스 로직을 처리하고 데이터베이스를 운영하는 데 문제가 없지만User.aspx.cs, 레이어링을 한다면 이런 작업은 하지 않는 것이 좋습니다. 계층적 구조에서는 User.aspx.cs 디스플레이와 관련된 콘텐츠만 다루고 그 외에는 포함되지 않아야 합니다.
예를 들어, 사용자 표시 기능을 리스트 형태로 구현하면 정보 추출 작업은 BLL이 수행하고, UI(이 경우 User.aspx.cs)가 BLL을 호출해 UserInfo를 얻으면, User.aspx의 데이터 제어에 코드 형태로 묶여 목록 표시를 구현합니다. 이 과정에서 UI User.aspx.cs 역할은 하지 않고 데이터 전달에만 사용되며, 대부분의 실제 코딩이 이렇게 구현되기 때문에 일부 사람들은 User.aspx.cs UI로 간주하지 않고 논리적 처리를 위해 BLL에 병합해야 한다고 생각합니다. 더 나아가 각 사용자 앞에 성별을 생생하게 나타내는 아이콘을 추가하는 새로운 요구사항이 제기되었고, 18세 미만의 경우에는 아동 아이콘으로 표현되었습니다. 이 요구사항의 실현이 바로 User.aspx.cs의 전환이며, 이 경우 실제로 User.aspx.cs 사용됩니다.
2, NewBLL.cs
다음 방법을 추가하세요:
public IList GetUsers(): 모든 사용자 정보 목록을 반환합니다
public UserInfo GetUser(int UserId): 지정된 사용자의 정보를 반환합니다
퍼블릭 bool AddUser(UserInfo User): 추가된 사용자 정보
public bool ChangeUser(UserInfo User): 사용자 정보를 업데이트합니다
공공 공무 RemoveUser(int UserId): 사용자 정보를 제거합니다
이 파일은 비즈니스 로직 계층에 속하며 비즈니스 로직과 관련된 작업을 처리하는 데 전념합니다. 많은 사람들은 이 계층의 유일한 용도가 성능 계층에서 데이터 계층으로 데이터를 전달하는 것이라고 생각할 수 있습니다. 실제로 그런 경우가 많지만, 이는 프로젝트가 비교적 단순하거나, 프로젝트 자체와 비즈니스 간의 관계가 밀접하게 통합되어 있지 않거나(예: 현재 인기 있는 MIS) 비즈니스 계층이 아무 역할도 하지 않고 전달 역할만 한다는 의미일 수 있습니다. 하지만 이것이 비즈니스 계층이 대체된다는 의미는 아닙니다. 프로젝트가 확대되거나 비즈니스 관계가 늘어나면서 비즈니스 계층은 그 역할을 반영합니다.
여기서 가장 가능성 높은 오류는 데이터 연산 코드를 비즈니스 로직 계층에, 데이터베이스를 데이터 접근 계층으로 할당하는 것입니다.
예를 들어, 일부 친구들은 BLL 계층이 의미가 없다고 느끼지만, 그냥 DAL 데이터를 업로드해서 아무런 처리 없이 UI로 전달하기도 합니다. 이 예를 한번 보세요
BLL 계층
SelectUser(UserInfo userInfo)는 들어오는 사용자 이름이나 이메일을 기반으로 사용자 정보를 받습니다.
IsExist(UserInfo userInfo)는 지정된 사용자 이름이나 이메일이 존재하는지 여부를 결정합니다.
그 후 DAL은 BLL 호출에 대응하는 메서드도 제공합니다
SelectUser(UserInfo userInfo)
IsExist(사용자 정보 사용자 정보)
이런 점에서 BLL은 단지 전달 역할만 합니다.
하지만 만약 그렇게 한다면:
정말 좋았어요. IsExist(Userinfo userinfo)
{
UerInfo 사용자 = DAL. 셀렉트유저(User);
return (userInfo.Id != null);
}
따라서 DAL은 IsExist() 메서드를 구현할 필요가 없으며, BLL에는 논리 처리 코드가 존재합니다.
3, UserModel.cs
엔티티, 이 존재는 계층화가 쉽지 않다고 생각할 수도 있습니다. 저를 포함해서도 이렇게 이해했습니다: UI?àModel?àBLL?àModel?àDAL, 즉 이 모델이 계층 간 데이터 전송의 다리 역할을 한다고 믿습니다. 하지만 여기서는 단순한 것들이 아니라 복잡성에 대해 생각한다.
모델이란 무엇인가요? 아무것도 아니에요! 3층 아키텍처에서는 필수입니다. 사실 객체지향 프로그래밍에서 가장 기본적인 것은 클래스입니다. 테이블은 클래스이고, 뉴스도 클래스이며, int, string, doublie 등도 클래스입니다. 그냥 클래스일 뿐입니다.
이렇게 하면 3계층 아키텍처에서 모델의 위치는 정수(int)나 문자열(string)과 같은 변수의 상태와 동일하며, 다른 목적은 없고 데이터 저장에만 사용되지만 복잡한 데이터를 저장합니다. 따라서 프로젝트 내 객체가 매우 단순하다면, 모델 없이 여러 매개변수를 직접 전달하여 3계층 아키텍처를 만들 수 있습니다.
그렇다면 왜 모델이 필요하며, 그 장점은 무엇일까요? 다음은 질문을 생각할 때 떠오르는 내용이며, 여기에 삽입합니다:
모델이 각 계층에서 매개변수 전달에 더 큰 역할을 할 수 있을까요?
레이어 간 매개변수를 전달할 때 다음과 같은 작업을 할 수 있습니다:
AddUser(userId, userName, userPassword,...,)
또한 다음과 같이 할 수도 있습니다:
AddUser(userInfo)
이 두 방법 중 어느 쪽이 더 나은가요? 언뜻 보기에는 두 번째가 훨씬 나은 것 같다.
정수, 문자열, guid, double이 있는 일반 변수 타입의 레이어 간에 매개변수를 언제 전달해야 하고, Model에서는 무엇을 전달해야 할까요? 다음 방법들:
SelectUser(int UserId)
SelectUserByName(문자열 사용자 이름)
SelectUserByName(문자열 사용자 이름, 문자열 비밀번호)
SelectUserByEmail(문자열 이메일)
SelectUserByEmail(문자열 이메일, 문자열 비밀번호)
요약하면 다음과 같습니다:
SelectUser(userId)
셀렉트유저(사용자)
여기서는 사용자 모델 객체를 사용하여 사용자 이름, 비밀번호, 이메일의 네 가지 조합 모드를 포함합니다. UserId도 사용자 폴더에 병합할 수 있지만, 프로젝트 내 다른 BLL은 id 매개변수를 가진 인터페이스를 구현하므로 이 항목도 유지됩니다.
userInfo가 전달되니 어떻게 처리할지는 순서대로 해야 하고, 결정해야 할 특정 코드가 있습니다.
여기서는 다음과 같은 순서로 처리됩니다
먼저 사용자 이름과 비밀번호가 있는지 확인하고, 이메일과 비밀번호가 있는지 확인하고, 사용자 이름이 있는지 확인한 다음, 이메일이 있는지 확인하세요. 순차적으로 처리됩니다.
이렇게 하면 앞으로 회원 카드(번호)라는 새로운 콘텐츠가 추가될 때 인터페이스를 변경할 필요 없이 DAL 코드에 번호 지원을 추가한 뒤, 전경에 회원 카드 콘텐츠의 성능과 처리만 추가할 수 있습니다.
4, UserDAL.cs
public IList SelectUsers(): 모든 사용자 정보 목록을 반환합니다
public UserInfo SelectUser(int UserId): 지정된 사용자의 신뢰할 수 있는 정보를 반환합니다
public bool InsertUser(UserInfo User): 사용자 정보 추가됨
public bool UpdateUser(UserInfo User): 사용자 정보를 업데이트합니다
공용 공무 DeleteUser(int UserId): 사용자 정보를 제거합니다
많은 사람들이 가장 잘 이해하지 못하는 것은 데이터 접근 계층인데, 어떤 부분이 데이터 접근 계층으로 간주되는가입니다. 일부 사람들은 데이터베이스가 데이터 접근 계층이라고 생각하지만, 정의가 명확하지 않습니다. DAL은 데이터 접근 계층이지 저장 계층이 아니므로 데이터베이스는 이 계층일 수 없습니다. SQLHelper의 역할은 반복적인 코딩을 줄이고 코딩 효율성을 향상시키는 것입니다. 예를 들어, 효율성에 관심이 많거나 데이터베이스가 아닌 데이터 소스를 사용하는 데 익숙하다면, 언제든지 버릴 수 있는 SQLHelper를 버릴 수 있습니다. 이 부분은 3계층 아키텍처의 한 레이어가 될 수 있겠습니까?
다음과 같이 정의할 수 있습니다: 데이터 소스 작업과 관련된 코드는 데이터 액세스 계층에 위치해야 하며, 이 계층은 데이터 접근 계층에 속합니다
5, IUserDAL
데이터 액세스 레이어 인터페이스도 필수인데, Petshop이 ClassFactory와 ClassFactory를 함께 제공하기 때문에, 일부 프로젝트는 여러 데이터 소스를 지원할지 여부와 상관없이 이 두 가지를 수행합니다. 어떤 프로젝트는 ClassFactory를 구축하지 않고 IDAL만 구축한 뒤, "IUserDAL iUserDal = new UserDAL(); 무슨 뜻인지 모르겠어. 이건 완전히 호랑이이지 반도그가 아니에요.
많은 사람들이 오해를 가지고 있는데, 즉 BLL과 DAL 사이의 다리 역할을 한다고 생각하는 BLL?àIDAL?àDAL입니다. BLL은 IDAL을 통해 DAL을 호출합니다. 하지만 현실은 이렇게 코딩해도 "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); "iUserDal.SelectUsers()"를 실행할 때는 실제로 실행되는 것은 IUserDAL 인스턴스가 아니라 UserDAL 인스턴스이므로, 세 번째 계층에서 IDAL의 위치는 DAL 레벨과 관련이 있습니다.
위의 소개를 통해 3단계 아키텍처의 계층 구조가 기본적으로 설명됩니다. 사실, 저는 3계층 아키텍처가 표준인지 판단할 방법이 있습니다. 즉, 세 계층 중 어느 하나라도 완전히 교체해도 나머지 두 계층에는 영향을 주지 않으며, 이런 구조는 기본적으로 3계층 표준을 충족합니다(구현은 더 어렵^_^지만). 예를 들어, 프로젝트를 B/S에서 C/S로 변경하거나 그 반대로 변경하면, BLL과 DAL은 UI만 변경할 필요가 없습니다; 또는 SQLServer를 Oracle으로 바꾸거나, SQLServerDAL을 OracleDAL로 바꾸면 다른 연산이 필요 없습니다. 원래는 특정 코드를 추가하려고 했지만, 필요하다고 느끼지 않아서 필요하신다면 추가하겠습니다.
요약: 레이어가 당신에게 쓸모없거나, 구현이 간단하거나, 포기하거나, 다른 용도로 사용한다고 해서 불필요하다고 생각하지 마세요. 레이어가 수행되는 한, 몇 개의 레이어가 있든 각 레이어는 명확한 목적과 기능을 가져야 하며, 실제 프로세스에 휘둘려 같은 유형의 파일이 서로 다른 레이어에 위치하게 해서는 안 됩니다. 같은 계층이 다른 기능을 구현하지 않도록 하세요. |
게시됨 2015. 5. 7. 오전 10:53:35
|
|
|
