명명 규칙 DAL, BAL 및 UI 계층 [닫기]

다음 레이어로 일반적인 웹 응용 프로그램을 개발 중입니다.

1. UI 레이어 (MVC)
2. 비즈니스 로직 계층 (BAL)
3. 데이터 액세스 계층 (DAL)

각 계층에는 BAL 및 DAL을 포함하여 자체 DTO 객체가 있습니다. 이것에 관한 나의 질문은 다음과 같습니다

1. DAL이 반환 한 DTO는 BAL에서 해당 DTO로 변환되어 UI 계층으로 전송됩니다. 경우에 따라 DTO 개체의 특성과 구조가 동일합니다. 이러한 시나리오에서는 중간 개체를 포함하지 않고 DAL의 DTO를 UI 계층으로 간단히 반환하는 것이 좋습니다.

2. 각 계층에서 이러한 DTO 개체 및 기타 개체의 이름을 지정하는 가장 좋은 방법은 무엇입니까? DTOName, ServiceName과 같은 접두사를 사용해야합니까? 접두사를 사용하도록 요청하는 이유는 솔루션의 클래스가 Framework의 다른 클래스와 충돌하지 않으면 접두사를 사용하여 각 클래스의 위치를 ​​쉽게 이해할 수 있기 때문입니다.

머리말

희망이 아래에 제안 된 네임 스페이스에, 당신은 대체 할 ... 분명하지만, MyCompany그리고 MyProject기업 및 프로젝트의 실제 이름.

DTO

모든 계층에서 동일한 DTO 클래스를 사용하는 것이 좋습니다. 그런 식으로 유지 관리 지점이 줄어 듭니다. 나는 보통 MyCompany.MyProject.Models같은 이름의 자체 VS 프로젝트에서 네임 스페이스 아래에 넣습니다 . 그리고 나는 보통 그들이 나타내는 실제 실체의 이름을 따서 간단히 이름을 붙입니다. (사실 데이터베이스 테이블도 같은 이름을 사용하지만 때로는 스키마를 조금 다르게 설정하는 것이 좋습니다.)

예 : Person, Address,Product

종속성 : 없음 (표준 .NET 또는 도우미 라이브러리 이외)

DAL

여기서 개인적으로 선호하는 것은 DTO 클래스와 일치하지만 MyCompany.MyProject.DataAccess네임 스페이스 / 프로젝트 에서 일대일 DAL 클래스 세트를 사용하는 것 입니다. 여기서 클래스 이름은 Engine충돌을 피하기 위해 접미사로 끝납니다 . (이 용어가 마음에 들지 않으면 DataAccess접미사도 잘 작동합니다. 선택한 것과 일관성이 있습니다.) 각 클래스는 대부분의 입력 매개 변수 및 반환 유형에 대해 DTO 클래스를 사용하여 데이터베이스에 타격을주는 간단한 CRUD 옵션을 제공합니다 (내부 List예를 들어, Find()메소드 로부터의 리턴이 하나 이상인 경우 의 총칭 .

예 : PersonEngine, AddressEngine,ProductEngine

종속성 : MyCompany.MyProject.Models

발 / BLL

또한 일대일 매핑이지만 MyCompany.MyProject.Logic네임 스페이스 / 프로젝트 및 클래스에 Logic접미사 가 붙습니다. 이것은 DAL을 호출하는 유일한 계층 이어야합니다 ! 여기에있는 수업은 종종 DAL에 대한 간단한 통과 과정이지만 비즈니스 규칙을 구현해야 할 경우에는 바로 여기에 있습니다.

예 : PersonLogic, AddressLogic,ProductLogic

종속성 : MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

웹 서비스 API 계층이있는 경우 동일한 일대일 접근 방식을 사용하지만 클래스 접미사 MyCompany.MyProject.WebApi와 함께 네임 스페이스 / 프로젝트에서 사용 Services합니다. ASP.NET 웹 API를 사용하지 않는 경우 Controller접미사를 대신 사용하십시오 .

예 : PersonServices, AddressServices,ProductServices

종속성 : MyCompany.MyProject.Models, MyCompany.MyProject.Logic(DAL을 직접 호출하여 이것을 우회하지 마십시오!)

비즈니스 로직에 대한 관찰

사람들이 BAL / BLL을 제외하고 가장 논리적 인 위치에있는 하나 이상의 다른 계층에서 비즈니스 로직을 구현하는 것이 점점 더 일반화되고 있습니다. 이렇게하면 (1) 모든 응용 프로그램 코드가 비즈니스 로직과 함께 계층을 통과하고 (2) 각 특정 비즈니스 규칙이 구현 된 위치에 명확하고 잘 문서화되어 있는지 확인하십시오. 의심스러운 경우 집에서 시도하지 마십시오.

엔터프라이즈 급 아키텍처에 대한 최종 참고 사항

대기업에 있거나 같은 데이터베이스 테이블이 여러 응용 프로그램에서 공유되는 다른 상황 MyProject인 경우 위의 네임 스페이스 / 프로젝트에서 해당 부분을 남겨 두는 것이 좋습니다 . 그렇게하면 여러 프런트 엔드 응용 프로그램 (및 Windows 서비스와 같은 비하인드 유틸리티)에서 해당 계층을 공유 할 수 있습니다. 그러나 강력한 팀 간 커뮤니케이션과 철저한 자동 회귀 테스트가있는 경우에만이 작업을 수행하십시오 !!! 그렇지 않으면 한 팀의 공유 핵심 구성 요소가 변경되어 다른 팀의 응용 프로그램이 손상 될 수 있습니다.

나는 보통 다음과 같이 응용 프로그램을 빌드합니다.

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

Sharp-Lite 와 다소 유사합니다 .

접두사에 대해, 나는 그들을 싫어. Microsoft의 내부 코딩 지침도 미워합니다. 또한 접두사에 대해 불평하는 StyleCop이라는 도구가 있습니다.