nier 응용 프로그램 만들기

Question

새로운 디자인 패턴입니다. 3 계층 아키텍처 구축 방법을 배우고 싶습니다. 나는 수색했지만 혼란 스러웠다. 이 기사에서는 http://www.dotnetfunda.com/articles/show/18/4-tier-architecture-in-aspnet-with-csharp 작성자가 Business Object 계층이라는 또 다른 계층을 추가합니다. 나에게 따르면 하나의 계층에서 다른 계층으로 데이터를 전송하는 것이 매우 유용합니다. 이 계층에는 비즈니스 개체 만 포함되므로 다른 계층에이 계층의 참조를 추가 할 수 있으며 규칙을 위반하지 않습니다.

하지만 다른 기사에서는 DTO를 사용하고 있습니다. 이 방법을 사용하여 DAL과 BAL간에 데이터를 변환해야합니다.

비즈니스 개체 계층을 사용하는 것이 더 논리적이고 쉽고 사용의 단점을 볼 수 없다고 생각합니다.

안정적인 해결책을 찾도록 도와주세요. 감사합니다.

Answer 1

전체 응용 프로그램에서 전역 계층으로 비즈니스 개체를 사용하고 있기 때문에 자체 계층을 사용할 수 있습니다. 비즈니스 객체는 구현에 특화된 것이 아니기 때문에 외부 의존성과 긴밀하게 연결되어서는 안된다. 그것은 Linq to Sql과 같은 데이터 액세스 기술을 사용하지 않고 있다고 가정합니다. Sql 특정 코드가 객체에 필요합니다.

지난 몇 년 동안, 나는 '양파 아키텍처'디자인으로 옮겼습니다. 필자는 비즈니스 개체 (엔터티)와 인터페이스를 핵심 프로젝트에 보관합니다. 모든 비즈니스 코드와 구현 관련 코드를 서비스 프로젝트에 추가하고 마지막으로 표준 UI 프로젝트를 추가합니다. UI 및 서비스 프로젝트는 각각 핵심에 대해서만 인식합니다. 모든 서비스는 핵심 인터페이스 중 하나를 구현하며 UI 코드는 구체적인 서비스 구현이 아닌 핵심 인터페이스에 대해 작성됩니다. 이런 방식으로 내 UI와 서비스는 완전히 분리되고 서로에 대한 지식이 없습니다. 이 패턴은 또한 다른 프로젝트를 포함하도록 확장 될 수 있습니다 (예 : 로깅과 같은 교차 절단 문제에 대한 인프라 사용).

n 티어 방식의 경우에도 비즈니스 개체 계층은 문제가 없다고 생각합니다. 또한 일종의 네이티브 데이터 레코드 (C#의 DataTable 등)를 비즈니스 계층에 반환하고 개체를 유지하며 네이티브 데이터 형식을 받아들이는 생성자를 포함 할 수 있습니다.