새해에는 아무데도 가지 않아서 집에 머물면서 여러분과 공유하고자 블로그를 몇 개 작성했습니다. 나는 보통 직장에서 매우 바쁘고 무언가를 쓸 시간이 거의 없습니다. 새해 전날과 새해 첫날에 이전 글을 올렸는데 저처럼 동행하는 블로거들이 정말 많아요 하하.
위의 내용은 ORM 계층과 비즈니스 계층을 대략적으로 소개한 것입니다. ORM은 주로 데이터 액세스를 위한 것으로 일상적인 저장 프로시저 호출 및 오류가 발생하기 쉬운 Sql 문에서 프로그램을 해제합니다. 아주 작은 BS 소프트웨어의 경우 이미 이 두 계층을 갖는 것이 가능하지만 통합 및 클라이언트를 고려하려는 경우 이들만으로는 충분하지 않고 데이터 처리의 유연성이 충분하지 않으며 클라이언트 인터페이스가 너무 긴밀한 결합을 보여줍니다. 비즈니스 로직 레이어와 함께.
다음은 데이터 교환 계층, 서비스 계층 및 DTO 계층을 소개합니다. 먼저 DTO 레이어부터 소개하겠습니다.DTO 레이어의 경우 일부 친구들은 필요 없다고 느낄 수 있습니다.추가 레이어가 있거나 그럴 수도 있습니다. 복잡성, 업무량, 사람에 대한 더 높은 요구 사항, 더 높은 비용 등은 모두 고려해야 할 측면입니다.
DTO계층 즉, 서버와 클라이언트간 통신을 하며, 비즈니스 로직 계층의 데이터를 클라이언트로 전달한 후 클라이언트의 데이터를 서버로 전달하여 데이터 교환이 이루어지며, 데이터 교환은 나중에 소개합니다. DTO의 데이터는 클라이언트의 데이터 바인딩을 지원할 수 있어야 합니다.어떤 친구는 비즈니스 계층의 데이터를 사용할 수 없습니까? 답은 근거리 통신망 내에 있으면 광역 통신망에서는 불가능하다는 것입니다. 늦게 로드되는 비즈니스 계층에 많은 데이터가 있고 네트워크에서 데이터를 전송할 때 일반적으로 한 번에 많은 양의 데이터를 전송해야 하므로 일반적인 성긴 설계입니다. 연결이 너무 크고 지연이 너무 큽니다. . 또한, 고객