사용자 인터페이스 표현 계층 (USL), 비즈니스 논리 계층 (BLL) 및 데이터 액세스 계층 (DAL)
BLL 은 USL 을 DAL 에서 분리하여 비즈니스 규칙 1 의 다양한 계층 기능을 추가합니다. 데이터 액세스 계층: 주로 원시 데이터가 아닌 원시 데이터 (데이터베이스 또는 텍스트 파일 등 저장된 데이터 형식) 의 운영 계층입니다. 즉, 데이터베이스가 아닌 데이터 작업입니다. 특히 비즈니스 논리 계층입니다
2. 비즈니스 논리 계층: 주로 특정 문제에 대한 작업으로, 데이터 계층의 운영 및 데이터 업무의 논리적 처리로 이해할 수 있습니다. 데이터 레이어가 블록인 경우 논리적 레이어는 이러한 블록의 구조입니다.
3. 표현 계층: 주로 웹 모드, WINFORM 모드, 웹 모드는 aspx 로 표시할 수 있습니다. 논리적 계층이 상당히 강력하고 완벽하다면 표현 계층이 어떻게 정의되고 변경되든 논리 계층은 완벽하게 서비스를 제공할 수 있습니다. 특정 구분 방법
1: 데이터 액세스 계층: 주로 데이터 계층에 논리적 처리가 포함되어 있는지 여부에 따라 달라집니다. 사실, 그 기능은 주로 데이터 파일에 대한 다양한 작업을 완료하는 것입니다. 다른 작업은 고려하지 않습니다.
비즈니스 논리 계층: 주로 데이터 계층 작업을 담당합니다. 즉, 일부 데이터 계층의 작업을 통합합니다.
3. 표현 계층: 주로 사용자의 요청 수락 및 데이터 반환에 사용되며 클라이언트에 응용 프로그램에 대한 액세스를 제공합니다. 3 계층 구조 해석
소위 3 계층 아키텍처는 클라이언트와 데이터베이스 사이에 중간 계층을 추가합니다. 이를 구성 요소 계층이라고도 합니다. 여기서 말하는 3 계층 체계는 물리적 3 층을 말하는 것이 아니라, 단순히 3 대의 기계나 3 계층 아키텍처를 넣는 것이 아니라, B/S 애플리케이션만이 3 계층 아키텍처인 것이 아니라, 3 계층은 논리적 3 층을 가리킨다. 비록 이 3 층이 한 대의 기계에 놓여 있다 해도. 3 계층 애플리케이션은 비즈니스 규칙, 데이터 액세스, 합법성 검증 등의 작업을 중간 계층에 배치하여 처리합니다. 일반적으로 클라이언트는 데이터베이스와 직접 상호 작용하지 않고 COM/DCOM 통신을 통해 중간 계층과 연결을 설정한 다음 중간 계층을 통해 데이터베이스와 교환합니다.
개발자는 응용 프로그램의 비즈니스 논리를 중간 계층 응용 프로그램 서버에 배치하고 응용 프로그램의 비즈니스 논리를 사용자 인터페이스에서 분리할 수 있습니다. 클라이언트 기능을 보장하면서 사용자에게 간단한 인터페이스를 제공합니다. 즉, 응용 프로그램 코드를 수정해야 하는 경우 수천 개의 클라이언트 응용 프로그램이 아닌 중간 계층 응용 프로그램 서버만 수정하면 됩니다. 개발자가 애플리케이션 시스템의 핵심 비즈니스 논리를 분석, 설계 및 개발하는 데 집중할 수 있도록 하여 애플리케이션 시스템의 개발, 업데이트 및 업그레이드를 단순화합니다. 그렇다면 왜 "중간 비즈니스 계층" 을 적용해야합니까? 몇 가지 예를 들어 보겠습니다.
로그인 코드가 있다고 가정하면 웹 프로그램을 이렇게 처리할 수 있습니다. 스킨 레이어는 포그라운드 페이지에서 데이터를 수신한 다음 중간 계층으로 전달하고 중간 계층은 서식 지정, SQL 주입 방지 등과 같은 데이터를 처리합니다. 이러한 데이터는 데이터 액세스 계층으로 다시 전달된 다음 데이터베이스의 사용자 이름과 암호 일치 등과 같은 데이터베이스와 작동합니다.
중간 비즈니스 계층은 사용자 입력 데이터 검증, 데이터베이스에서 읽은 데이터 캐시 등 다양한 용도로 사용됩니다. 그러나 중간 비즈니스 계층의 실제 목적은 데이터 액세스 계층의 가장 기본적인 스토리지 논리를 결합하여 비즈니스 규칙을 형성하는 것입니다. 예를 들어, "한 쇼핑 사이트에는 해당 사이트에서 처음 쇼핑하는 사용자가 시스템에 자동으로 등록된다는 규정이 있다." 이러한 비즈니스 논리는 중간 계층에 두는 것이 가장 좋습니다. "데이터 액세스 계층" 에서는 "비즈니스 논리" 를 갖지 않는 것이 좋습니다! 즉, 우리는' 데이터 액세스 레이어' 에서 함수의 원자성을 보장해야 한다! 즉, 미니멀리즘과 불가분성입니다. 데이터 액세스 계층은 데이터 저장 또는 읽기만 담당합니다.
ASP.NET 의 3 계층 구조 설명
정교한 3 계층 구조의 요구 사항은 표현 계층을 수정해도 논리 계층은 수정되지 않고 논리 계층을 수정해도 데이터 계층은 수정되지 않는다는 것입니다. 그렇지 않으면 응용 프로그램이 다중 계층 구조인지, 계층 구조의 분할과 조직에 문제가 있는지 말하기는 어렵습니다. 응용마다 다른 이해가 있는데, 이것은 단지 개념상의 문제일 뿐이다. ASP 의 3 계층 구조를 이해합니다. 넷-왜 3 층으로 나눠야 하나요?
우리는 주로 프로젝트 구조를보다 명확하게 만들고, 분업을보다 명확하게 만들고, 사후 유지 보수 및 업그레이드에 도움이되는 3 계층 구조를 사용합니다. 마스터 프로그램 모듈은 하위 프로그램 모듈이 실행되지 않을 때만 대기 중이기 때문에 성능이 향상되지 않을 수 있습니다. 따라서 애플리케이션 계층화는 실행 속도에 약간의 손실을 초래할 수 있습니다. 하지만 팀 개발 효율성의 관점에서 우리는 전혀 다른 효과를 느낄 수 있다.
3 계층 구조는 특허가 아니라는 점에 유의해야 한다. 그물, 데이터베이스 전용 기술도 아닙니다. 좀 더 일반적인 건축 설계 개념입니다.
이 스키마는 데이터베이스 설계에서 테이블과 테이블 간의 관계에 주의를 기울여 마스터-슬레이브 관계를 최대한 만족시켜야 합니다. 사용자의 기능에는 몇 가지 제한이 있어야 하며, 마스터 및 하위 테이블의 데이터에 논리적 오류가 발생하지 않도록 하위 테이블을 삭제할 때 주의해야 합니다. 마스터 테이블의 외래 키는 하위 테이블에 해당 값이 없습니다. 이 테이블의 통합 쿼리 방법은 다음과 같습니다.
먼저 마스터 테이블을 쿼리하고 마스터 테이블에 해당하는 DL 을 호출합니다. 그런 다음 마스터 테이블의 레코드를 기준으로 각 하위 테이블을 질의합니다. 테이블의 질의 결과를 마스터 테이블에 추가하면 큰 질의 세트가 형성됩니다.
테이블 작업 (추가, 삭제 및 수정) 의 경우 ：
이 시점에서 마스터 테이블만 작동하고 마스터 테이블에 해당하는 DL 에서 작업 메소드를 호출합니다.
RL 계층은 페이지에 업로드된 데이터를 주로 결정하는 논리적 판단 계층입니다. RL 계층 위에는 UI 가 3 계층 아키텍처 솔루션을 구축하는 방법이 있습니다.
새로운 빈 솔루션을 만듭니다. 그리고 나서:
추가-신규 프로젝트-기타 프로젝트-엔터프라이즈 템플리트 프로젝트 -C # 빌딩 블록-데이터 액세스 (데이터 계층, 이하 d 계층)
추가-신규 프로젝트-기타 프로젝트-엔터프라이즈 템플리트 프로젝트 -C # 빌딩 블록-업무 규칙 (업무 계층, 이하 c 계층)
추가-신규 프로젝트-기타 프로젝트-엔터프라이즈 템플릿 프로젝트 -C # 빌딩 블록-웹 사용자 인터페이스 (인터페이스 계층, 이하 u 계층).
솔루션-프로젝트 종속성을 마우스 오른쪽 버튼으로 클릭하고 u 를 종속성 d 로, c 와 c 를 종속성 d 로 설정합니다.
참조 d 와 c 를 u 에 추가하고 참조 d 를 c 에 추가합니다.
지금까지 이미 3 층 선반을 세웠다. 내가 위에서 말한 것은 매우 구체적이고 어리석다. 아는 사람들은 모두 내가 헛소리를 하고 있다고 생각한다. 사실, 저는 많은 사람들이 이 간단한 과정을 전혀 이해하지 못한다는 강한 느낌을 가지고 있습니다. 두 개의' 빈 프로젝트' 와 1 도 3 계층 프레임워크로 사용될 수 있는' ASP 넷웹 애플리케이션 프로젝트' 를 구축하는 것에 반대하지 않지만, 상당수는 이러한' 엔터프라이즈 템플릿 프로젝트' 가 실제로 빈 프로젝트라고 생각하는 것은 오해이다. 예. 엔터프라이즈 템플릿 프로젝트는 솔루션 탐색기에서 아무 것도 아니지만 메모장을 사용하여 프로젝트 파일을 열 수 있습니다. 차이점을 보셨나요? 어떤 일들은 이미 지나갔지만, 시스템은 이미 준비되었다. 즉, C 계층의 한 클래스에서 "시스템 데이터 sqlclinic 사용" 또는 SqlConnection 객체를 사용하면 컴파일 시 오류가 발생하지 않지만 "작업 목록" 에 "정책 경고" 가 생성되어 D 계층에 배치해야 할 것을 C 계층 ( 새로운 Trace Word 3 에서 "엔터프라이즈 템플릿 프로젝트" 가 적용되었습니다. 원래 LWordTask.cs 를 AccessTask 라는 단일 프로젝트에 넣습니다. 솔루션에 중간 비즈니스 계층 프로그램인 프로그램 파일 LWordService.cs 가 포함된 InterService 라는 새 프로젝트가 생성됩니다. 중복 이름 지정을 피하기 위해 Trace Word 3 의 웹사이트는 WebUI 프로젝트에 있습니다. 더 완전한 코드는 코드 패키지 /trace word 3 디렉토리에서 찾을 수 있습니다. 객체와 현실의 결합입니다.
우리는 다리를 만드는 데 벽돌이 필요하다는 것을 알고 있기 때문에 다리를 만들기 전에 벽돌을 준비해야 하지만, 설명의 질서, 일관성, 간결성을 위해 준비해야 한다. 우리는 먼저 다리를 건설하고, 벽돌은 건설 과정에서 다시 생산해야 한다. 이렇게 하면 더 이상' 다리에 필요하지 않은 것' 이 없을 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 예술명언) 실제 작업에서 먼저 벽돌을 준비해야 한다는 점에 유의하십시오.
U 층은 사실 다리이고, C 층은 벽돌이고, D 층은 일종의 원자재 (석두, 모래) 이다. 또한 u 레이어가 U-to-C 및 C-to-D 레이어가 아닌 d 레이어를 참조하고 의존하는 이유를 설명합니다. 다리에는 벽돌뿐만 아니라 석두 및 모래가 필요하기 때문입니다. 3 층 구조' 의 단점은 네티즌이 글의 전작을 보고 나에게 몇 가지 질문을 한 것으로, 문장 때 지금까지' 3 층 구조' 에 대해 언급하지 않은 단점을 떠올리게 한다. "3 층 구조" 라는 단어가 항상 유행하는 것 같은데, 그 이유는 이런 개발 모델이 널리 사용되고 있기 때문일 것이다. 그러나' 3 층 구조' 는 백령의 만병통치약이 아니며 단점도 있다. 그것의 단점을 먼저 말하다 ...' 3 계층 구조' 개발 모델의 한 가지 명백한 단점은 실행 속도가 충분히 빠르지 않다는 것이다. 물론, 이 "실행 속도" 는 계층화되지 않은 응용 프로그램과 관련이 있습니다. 이 글에서 제시한 시순도를 보면, 이 단점도 뚜렷하게 드러났다. TraceLWord 1 및 TraceLWord2 는 계층화되지 않고 ADO.NET 에서 제공하는 클래스를 직접 호출하여 데이터를 가져옵니다. 그러나 추적 단어 6 은 데이터를 얻기 위해 여러 번 호출해야 합니다. 하위 프로그램 모듈 프로그램이 반환되지 않으면 마스터 프로그램 모듈은 대기 상태로만 유지될 수 있습니다. 따라서 실행 속도에서 게시판 버전이 높을수록 순위가 낮아진다. "3 계층 구조" 개발 모델은 온라인 예약, 온라인 주식 거래 등 실행 속도가 너무 엄격한 시스템에는 적합하지 않습니다. 비즈니스 규칙이 쉽게 바뀌는 시스템에 더 적합합니다. "3 계층 구조" 개발 모델, 입문 어려움, 학습난을 이해하다. 이것은 프로그래머를 위한 것이다. 이 모드에서 개발된 소프트웨어에는 일반적으로 더 많은 코드가 있습니다. 이것은 종종 초보자를 연기와 같은 코드에 잠기게 한다. 이에 대한 두려움과 혐오감은 이해할 수 있다. 사실 어떤 개발 모델이든 어떤 개발 방법이든 장단점이 있다. 어떤 문제도' 사방에 널리 퍼져 있다' 는 해결책이 없을 것이다. 그래서' 3 층 구조' 라는 단어도 예외는 아닙니다! 이런 모델을 채택하여 시스템 개발을 할 것인지의 여부는 비교적 균형 잡힌 후에야 할 수 있다. 남용을 피하십시오!