효율성을 유지하면서 비즈니스 로직과 사용자 인터페이스를 분리하려면 어떻게해야합니까?

콤보 상자에 10 개의 서로 다른 객체를 나타내는 양식을 표시하려고한다고 가정하겠습니다. 예를 들어, 사용자가 토마토를 포함하는 10 개의 다른 햄버거에서 하나의 햄버거를 선택하기를 원합니다.

UI와 논리를 분리하고 싶기 때문에 햄버거를 콤보 상자에 표시하려면 햄버거의 문자열 표현을 양식에 전달해야합니다. 그렇지 않으면 UI가 객체 필드를 파헤쳐 야합니다. 그런 다음 사용자는 콤보 박스에서 햄버거를 골라 컨트롤러에 다시 제출합니다. 이제 컨트롤러는 양식에 사용 된 문자열 표현 (ID 일 수 있음)을 기반으로 함부르크를 다시 찾아야합니다.

그렇게 비효율적이지 않습니까? 당신은 이미 당신이 고르고 싶은 물건을 가지고있었습니다. 양식에 전체 객체를 제출 한 다음 특정 객체를 반환 한 경우 양식이 이미 해당 객체에 대한 참조를 반환했기 때문에 나중에 다시 정의하지 않아도됩니다.

또한 내가 틀렸고 실제로 전체 객체를 양식에 보내야하는 경우 UI를 로직에서 분리하는 방법은 무엇입니까?

^{우선, 당신이 제공 한 예제는 엄청나게 비효율적이지 않습니다. 그것의 약간 비효율적이다; 그것의 비효율은 지각 할 수있는 수준보다 낮습니다. 그러나 어쨌든 질문으로 넘어 갑시다.}

내가 이해하는 방식 은 UI와 로직 의 분리에 대해 말할 때 밀접한 결합을 피하는 것을 의미 합니다.

밀접한 결합 은 UI가 로직을 알고 (및 호출), 로직이 UI를 알고 (및 호출)하는 상황을 말합니다. 밀접한 결합을 피하기 위해 결합을 완전히 폐지 할 필요는 없습니다. (그것들 사이의 인터페이스를 최소 공통 분모 문자열 인터페이스로 분해하여 목표로하는 것 같습니다.) 필요한 것은 느슨한 결합 을 사용하는 것 입니다.

느슨한 결합 은 A는 B를 알고 있지만 B는 A를 모른다는 것을 의미합니다. 즉, 관련된 두 당사자 는 클라이언트가 서버를 알고 있지만 서버는 클라이언트를 모르는 별개의 클라이언트 및 서버 역할을 수행합니다.

UI와 로직의 경우 내 의견으로는 이것을 배치하는 가장 좋은 방법은 로직을 서버로보고 UI를 클라이언트로 보는 것입니다. 따라서 UI는 로직을 위해 빌드되고 로직에 대한 지식이 있으며 로직을 호출하는 반면 로직은 UI에 대해 아무것도 알지 못하고 수신하는 요청에 간단히 응답합니다. (이러한 요청은 UI에서 발생하지만 논리는이를 알지 못합니다.)

보다 실용적인 용어로, 로직의 소스 코드 파일 내에서 UI 파일을 참조하는 include / import / using 문을 찾지 못하면 UI의 소스 코드 파일은 include / import / using으로 가득합니다. 논리 파일을 참조하는 명령문.

따라서 다시 돌아와서 콤보 상자를 채우는 UI 코드가 햄버거 클래스에 대해 알고 있다는 사실에는 아무런 문제가 없습니다. 햄버거 클래스가 콤보 상자에 대해 알고 있다면 문제가있을 것입니다.

또한이 디자인은 그러한 시스템에서 기대할 수있는 또 다른 것을 허용합니다. 로직에 원하는만큼 많은 UI를 연결할 수 있어야하며 전체가 여전히 작동해야합니다.

Model, View & Controller의 각 부분 을 분리해야 하지만 Controller와 View간에 Model 객체를 전달할 수없는 이유는 없습니다.

따라서 귀하의 경우 Hamburger객체는 모델의 일부입니다. 그런 다음 Controller를 사용하여 필요한 목록을 가져오고 Hamburger해당 객체를보기 (콤보 박스)에 전달하여 표시합니다. 사용자가 햄버거를 선택한 Hamburger경우 처리를 위해 개체를 컨트롤러로 다시 전달할 수 있습니다 .

요점은 햄버거의 실제 디스플레이와 별도로 "fetch Hamburgers"로직과 "process Hamburger"로직을 개별적으로 테스트 할 수 있다는 것 입니다.