C# 3계층 아키텍처에 대한 심층 설명

이 글은 예제를 사용하여 3-tier 아키텍처 프로젝트를 구축하는 방법을 소개하고 프로젝트에서 각 파일의 수준과 역할을 설명합니다. 이 글을 쓰는 목적은 내 방법이 얼마나 정확한지 설명하기 위한 것이 아닙니다. 그러나 3계층 아키텍처를 처음 접했지만 어디서부터 시작해야 할지 모르는 친구들에게 도움을 주기를 바랍니다. 인터넷에 있는 대부분의 기사는 이론적 소개에 초점을 맞추고 특정 실제 적용을 무시합니다. 예제가 촘촘하지 않아서 읽은 후 이론적인 공부로 이어지지만 아직 코드를 어떻게 작성해야 할지 모르기 때문에 이 부분부터 시작해서 3-1을 해본 적이 없는 초보자들이 쓸 수 있도록 작성하고 싶습니다. 계층 아키텍처는 코드에 따라 코드를 작성할 수도 있습니다. 기사의 코드는 의사 코드이며 아이디어를 설명하는 데만 사용됩니다.

　텍스트

계층 아키텍처에서는 UI(프레젠테이션 계층), BLL(비즈니스 로직 계층), DAL(데이터 액세스 계층)이라는 것을 누구나 알고 있습니다. 3계층 아키텍처 프로젝트를 연습하기 위해 간단한 예를 사용하겠습니다. 이 예에는 간단한 사용자 관리 기능만 있습니다.

먼저 빈 솔루션을 만들고 다음 프로젝트 및 파일을 추가하십시오.

ASP NET 웹 애플리케이션 프로젝트를 추가하고 이름을 UI로 지정하십시오. 새 웹 양식 유형 파일인 User aspx(User aspx cs 포함)를 작성하십시오.

ClassLibrary 프로젝트를 추가하고 이름을 BLL로 지정합니다. 새 클래스 유형 파일을 생성합니다. UserBLL cs

ClassLibrary 프로젝트를 추가하고 이름을 DAL로 지정합니다. SQLHelper 참조를 추가합니다. (이것은 Microsoft의 데이터 액세스 클래스이며 직접 작성할 필요는 없습니다. 모든 데이터 액세스 코드를 작성할 때 일반적으로 직접 작성한 데이터 액세스 클래스 DataAccessHelper를 사용합니다.)

ClassLibrary 프로젝트를 추가하고 Model이라는 이름을 지정합니다. 새 클래스 유형 파일을 생성합니다. UserModel cs

ClassLibrary 프로젝트를 추가하고 이름을 IDAL로 지정합니다. 새 인터페이스 유형 파일을 생성합니다. IUserDAL cs

ClassLibrary 프로젝트를 추가하고 ClassFactory로 이름을 지정합니다.

아래 Petshop을 통해서도 3-Tier 아키텍처를 학습하기 때문에 이것이 Petshop 예시와 다르지 않고 더 간단하다는 것을 이미 보셨을 거라 생각합니다. 하지만 일부 친구들은 이러한 프로젝트의 수준과 관계에 대해 막연할 수도 있습니다. 하나씩 설명하겠습니다.

사용자 aspx와 사용자 aspx cs

이 두 파일(아래 파일이 속한 프로젝트도 마찬가지이므로 저는 다시 강조하지 않겠습니다) 모두 프레젠테이션 레이어 부분에 속합니다. 사용자 aspx는 페이지만 표시하기 때문에 이해하기 쉽습니다. 사용자 aspx cs는 계산되지 않고 비즈니스 로직 레이어에 포함되어야 한다고 생각하는 사람들도 있습니다. 레이어링을 하지 않으면 사용자 aspx cs가 비즈니스 로직을 처리하고 심지어 데이터베이스를 운영하는 데 문제가 없습니다. 그러나 레이어링을 하면 이러한 일이 발생해서는 안 됩니다. 디스플레이 관련 내용 및 기타 부분은 포함되어서는 안 됩니다.

예를 들어 사용자를 목록에 표시하는 기능을 구현하면 정보 추출 작업은 BLL에서 수행됩니다. UI(이 경우 사용자 aspx cs) BLL을 호출하여 UserInfo를 가져와 코드를 통해 바인딩합니다. 이 프로세스에서 사용자 aspx cs는 어떤 것도 재생하지 않습니다. UI에서의 역할은 데이터를 전송하는 데만 사용됩니다. 그리고 실제 코딩의 대부분의 상황이 이렇게 구현되기 때문에 일부 사람들은 사용자 aspx cs를 UI로 계산해서는 안 되고 BLL에 통합해야 한다고 생각합니다. 논리적인 처리를 담당해야 합니다. 계속해서 내려다보면 새로운 요구 사항이 제시됩니다. 사용을 생생하게 표현하려면 각 사용자 앞에 아이콘을 추가해야 합니다.

사용자의 성별과 10세 미만을 나타내는 하위 아이콘을 사용하여 이 요구 사항을 실현하는 것은 사용자 aspx cs의 차례입니다. 이 경우 사용자 aspx cs에는 실제 목적이 있습니다.

NewBLL cs

다음 메소드 추가

public IList GetUsers() 모든 사용자 정보 목록을 반환합니다.

public UserInfo GetUser(int UserId) 해당 사용자의 세부 정보를 반환합니다. 지정된 사용자

Public bool AddUser (UserInfo User) 사용자 정보 추가

Public bool ChangeUser (UserInfo User) 사용자 정보 업데이트

public void RemoveUser (int UserId) 사용자 정보 제거

이 파일은 비즈니스 로직 레이어에 속하며 특히 비즈니스 로직과 관련된 작업을 처리하는 데 사용됩니다. 많은 사람들은 이 레이어의 유일한 목적이 데이터를 전달하는 것이라고 생각할 수 있습니다. 실제로 이러한 상황은 많이 있지만 이는 프로젝트가 상대적으로 단순하거나 프로젝트 자체와 비즈니스 간의 관계가 밀접하게 통합되지 않았음을 보여줍니다(예: 현재 인기 있는 MIS). 비즈니스 계층은 아무 역할도 하지 않고 전달 역할만 하지만 이것이 비즈니스 계층이 필요하지 않다는 의미는 아닙니다. 프로젝트가 성장하거나 비즈니스 관계가 많아지면 비즈니스 계층이 그 역할을 반영하게 됩니다.

여기서 오류가 발생할 가능성이 가장 높은 원인은 데이터 작업 코드를 비즈니스 논리 계층에서 데이터베이스를 데이터 액세스 계층으로 사용하는 것입니다.

예를 들어 일부 친구는 BLL 계층이 별 의미가 없다고 생각합니다. DAL 데이터를 가져와 아무런 처리 없이 UI에 전달하기만 하면 됩니다. 이 예를 살펴보세요.

BLL 레이어

SelectUser(UserInfo userInfo)는 이를 기반으로 사용자 세부 정보를 얻습니다. 들어오는 사용자 이름 또는 이메일에 대해

IsExist(UserInfo userInfo)는 지정된 사용자 이름 또는 이메일이 존재하는지 확인합니다.

그런 다음 DAL은 해당 방법 ***BLL 호출도 제공합니다

SelectUser (UserInfo userInfo)

IsExist (UserInfo userInfo)

이런 식으로 BLL은 패스 역할만 합니다

하지만 이렇게 하면

BLL IsExist (Userinfo userinfo)

{

UerInfo user = DAL SelectUser(User)

return (userInfo Id != null)

　}

그러면 DAL은 논리 처리 코드를 사용하여 BLL에서 IsExist() 메서드를 구현할 필요가 없습니다.

UserModel cs

모두 엔터티 클래스는 레이어링이 쉽지 않다고 생각할 수도 있는데, 예전의 저를 포함해서 이렇게 이해했습니다. 하지만 여기서는 사물을 단순하게 생각하지 않고 복잡하게 생각합니다.

모델이란 무엇인가요? 그것은 아무것도 아니다! 3계층 아키텍처에서는 없어도 됩니다. 실제로 객체지향 프로그래밍에서 가장 기본적인 것입니다. 테이블도 클래스이고, 뉴스도 클래스이고, int 문자열도 클래스입니다. class.

이와 같이 3계층 아키텍처에서 Model의 위치는 int 문자열과 같은 변수의 위치와 동일하며 다른 용도로는 사용되지 않습니다. 매장만 있어요

복잡한 데이터이므로 프로젝트의 객체가 매우 단순하다면 모델을 사용하지 않고 여러 매개변수를 직접 전달하여 3계층 아키텍처를 만들 수 있습니다.

그러면 모델이 왜 필요한가요? 다음은 문제가 있을 때 생각해서 여기에 삽입한 것입니다.

각 레이어에서 매개변수를 전달하는 데 모델이 더 큰 역할을 할 수 있을까요?

레이어 간에 매개변수를 전달할 때 이 작업을 수행할 수 있습니다.

AddUser(userId userName userPassword...)

이 작업도 수행할 수 있습니다.

AddUser (userInfo )

이 두 가지 방법 중 어느 것이 더 낫습니까? 두 번째 방법이 훨씬 더 낫다는 것은 한 눈에 분명합니다.

일반 변수 유형(int 문자열)을 사용해야 하는 경우는 언제입니까? guid double) 레이어 간에 매개변수를 전달하려면 모델 전달을 사용하시겠습니까? 다음 방법

SelectUser (int UserId)

SelectUserByName (문자열 사용자 이름)

SelectUserByName (문자열 사용자 이름 문자열 비밀번호)

SelectUserByEmail ( 문자열 이메일)

SelectUserByEmail(문자열 이메일 문자열 비밀번호)

다음으로 요약될 수 있습니다.

SelectUser(userId)

SelectUser(사용자)

여기서 모델 개체 사용자는 세 가지 매개변수 사용자 이름 비밀번호 이메일의 네 가지 조합 모드를 포함하는 데 사용됩니다. UserId는 실제로 사용자로 병합될 수 있지만 프로젝트의 다른 BLL은 id 매개변수가 있는 인터페이스를 구현했습니다. 항목도 여기에 보관됩니다.

userInfo가 전달된 후 이를 어떻게 처리해야 합니까? 이는 순서대로 결정되어야 하며 특정 코드에 의해 결정되어야 합니다.

여기서는 이 순서대로 처리됩니다.

먼저 사용자 이름과 비밀번호가 모두 있는지 확인하고, 이메일과 비밀번호가 모두 있는지 확인하고, 사용자 이름이 있는지 확인하고, 이메일이 있는지 확인하고 순서대로 처리합니다

이 방법으로 향후 새로운 콘텐츠 멤버십 카드(번호)가 추가되면 인터페이스를 변경할 필요 없이 DAL 코드에 번호에 대한 지원만 추가한 다음 멤버십 카드의 성능 및 처리를 추가하면 됩니다. 프런트엔드의 콘텐츠

UserDAL cs

public IList SelectUsers() 모든 사용자 정보 목록을 반환합니다.

Public UserInfo SelectUser (int UserId) 반환 지정된 사용자의 신뢰 정보

Public bool InsertUser (UserInfo User) 새로운 사용자 정보 추가

Public bool UpdateUser (UserInfo User) 사용자 정보 업데이트

Public void DeleteUser (int UserId) 사용자 정보 제거

많은 사람들에게 가장 혼란스러운 것은 데이터 액세스 레이어입니다. 데이터 액세스 레이어는 어떤 부분인가요? 어떤 사람들은 데이터베이스가 데이터 액세스 계층이라고 생각하는데 이는 정의가 명확하지 않습니다. DAL은 데이터 저장 계층이 아닌 데이터 액세스 계층이므로 데이터베이스는 SQLHelper(또는 이와 유사한 구성 요소)가 될 수 없습니다. )를 데이터 액세스 계층으로 사용하는 것은 또 다른 필수 기능입니다. SQLHelper의 기능은 반복적인 코딩을 줄이고 코딩 효율성을 높이는 것입니다.

SQLHelper는 데이터베이스가 아닌 데이터 소스를 사용할 때 폐기될 수 있습니다. 폐기될 수 있는 부분이 어떻게 3계층 아키텍처에서 레이어가 될 수 있습니까?

데이터 소스 작업과 관련된 코드는 다음에서 정의할 수 있습니다. 데이터 액세스 레이어는 데이터 액세스 레이어에 속합니다.

IUserDAL

데이터 액세스 레이어 인터페이스는 Petshop에 있고 ClassFactory 클래스 팩토리가 있기 때문에 또 다른 필수 요소입니다. 따라서 일부 프로젝트에서는 여러 데이터 소스를 지원해야 하는지 여부에 관계없이 이 두 가지가 내장되어 있습니다. 일부는 ClassFactory를 빌드하지 않고 IDAL만 빌드한 다음 IUserDAL iUserDal = new UserDAL()이 무엇인지 모르겠습니다.

여기서 많은 사람들이 BLL?àIDAL?àDAL이라는 관계가 있다고 오해하고 있습니다. BLL은 IDAL을 통해 DAL을 호출합니다. 그러나 실제로 IUserDAL iUserDal = ClassFacotry CreateUserDAL()을 코딩하더라도 iUserDal SelectUsers()를 실행하면 실제로 IUserDAL 인스턴스 대신 UserDAL 인스턴스가 실행됩니다. 세 번째 레이어에서 IDAL의 위치는 DAL과 동일한 수준입니다.

위의 소개에서는 기본적으로 3티어 아키텍처의 계층 구조를 설명했습니다. 실제로 3티어인지 여부를 판단할 수 있는 방법이 있습니다. 즉, 3개 레이어 중 하나를 완전히 교체해도 나머지 2개 레이어에는 영향을 미치지 않습니다. (구현하기는 어렵지만^_^) 프로젝트를 B/S에서 C/S로(또는 그 반대로) 변경하면 UI를 제외하고 BLL 및 DAL을 변경할 필요가 없으며 SQLServer를 Oracle로 변경하기만 하면 SQLServerDAL을 OracleDAL로 교체하면 됩니다. . 원래 기사에 특정 코드를 추가하고 싶었지만 필요하다고 생각되면 추가하겠습니다. lixixinzhi/Article/program/net/201311/11365