개발 접근 방식 : 사용자 인터페이스 입력 또는 도메인 모델 출력?

스몰 토크를 사용하여 아무 것도 전달하지는 못했지만 짧은 시간을 보냈을 때 확실히 그 자리를 떠났습니다. 경험을 설명하는 유일한 방법은 MVC가 원래 의도했던 방식입니다. 기본적으로 응용 프로그램의 모든 작업은 비즈니스 개체 (또는 기울어 진 경우 도메인 모델)에서 수행됩니다. 표준 제어는 어떤 방식으로 비즈니스 오브젝트에 바인드됩니다. 예를 들어, 텍스트 상자는 객체의 필드에 매핑됩니다 (필드 자체는 객체이므로 쉽게 수행 할 수 있음). 버튼은 메소드에 매핑됩니다. 이것은 모두 매우 간단하고 자연스러운 API로 수행됩니다. 우리는 객체 바인딩 등에 대해 생각할 필요가 없습니다. 그냥 작동합니다.

그러나 많은 새로운 언어와 API에서는 외부에서 생각해야합니다. 먼저 C ++ 및 MFC, 이제 C # 및 WPF를 통해 Microsoft는 개발자가 이벤트 핸들러를 구현하여 응용 프로그램을 빌드하는 GUI 빌더에 매료되었습니다. . Java Swing 개발은 그다지 다르지 않습니다. 폼의 컨트롤을 직접 인스턴스화하는 코드 만 작성하면됩니다. 일부 프로젝트의 경우 이벤트 핸들러 만있는 도메인 모델이 없을 수도 있습니다. 나는 대부분의 내 간병인을 위해이 모델에 있었고 주변에있었습니다.

각 방법은 당신이 다르게 생각하도록 강요합니다. 스몰 토크 접근 방식을 사용하면 GUI가 멍청한 반면 도메인은 영리합니다. 기본 VisualStudio 접근 방식을 사용하면 GUI가 영리하지만 도메인 모델 (있는 경우)은 빈약합니다.

내가 함께 일하는 많은 개발자들은 스몰 토크 접근 방식에서 가치를보고 그 접근 방식을 VisualStudio 환경으로 끌어 올리려고 노력합니다. WPF는 가지고 어떤 것이 가능하게 기능을 동적 바인딩하는 단계; 그러나 한계가 있습니다. 필연적으로 도메인 모델에 속하는 일부 코드는 GUI 클래스로 끝납니다.

그렇다면 어떤 방법으로 코드를 디자인 / 개발합니까? 왜?

• GUI 먼저. 사용자 상호 작용이 가장 중요합니다.
• 도메인 우선. UI를 설치하기 전에 시스템이 올바른지 확인해야합니다.

두 가지 접근 방식에 대한 장단점이 있습니다. 도메인에는 크리스탈 대성당과 하늘의 파이가 들어 있습니다. GUI는 빠르고 더티 (때로는 더러워 짐)에 적합합니다.

그리고 추가 보너스 : 코드를 유지 보수 할 수 있는지 어떻게 확인합니까?

어느 쪽도

몇 년 동안 소프트웨어를 개발해 왔으며 항상 고려해야 할 "중간 영역"이 있기 때문에 두 가지 첫 번째 방법론 을 연습해야한다는 것을 알게되었습니다 . UI 코드와 비즈니스 코드 사이에 인터페이스를 배치하고 현재 도메인에서 UI에 필요한 것에 동의하십시오.

이 개념을 명확하게 보여줄 그림을 만들어 보겠습니다.

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

이렇게하면 중간 수준에서 UI가 수신 할 수있는 데이터를 명확하게 표시 할 경우 UI와 도메인 모델을 반복적으로 작업 할 수 있습니다.

일부 프로젝트를 유지할 수없는 이유 는 데이터와 프리젠 테이션 간의 인터페이스가 서두르거나 존재하지 않기 때문 입니다 (직접 데이터 처리 코드가 UI에 있음). 데이터베이스 코드가 양식 코드 내에 상주하여 인류에 대한 믿음을 잃은 프로젝트가 너무 많습니다. 내가 본 소수의 프로젝트 만이 믿음을 잃어버린이 견고한 중간 복원을 가지고 있습니다.

그것은 어떤에서 정말 중요하지 않습니다 결국 어떤 중요한 것은 당신이 가지고 있다는 것입니다 ... 처음 시작하는 경우 그 장소에서 우려의 명확한 seperation에. 중간에있는 계약은 현재 응용 프로그램이나 시스템을 정의합니다. 상향식 또는 하향식으로 가기 전에 먼저 생각하십시오 .

도메인 우선. UI를 설치하기 전에 시스템이 올바른지 확인해야합니다.

간단한 경우를 제외하고는 아무것도 작동시킬 수 없습니다.

UI에서 시작하면 종종 재미 있지만 모델에 심각한 문제가있는 깨지기 쉬운 버그가있는 소프트웨어가 생깁니다.

UI가 먼저 실패 할 운명은 아닙니다. 모델이 충분히 단순하다면 모델이 결국에는 잘 작동 할 것이라는 확신을 가지고 UI를 먼저 구축 할 수 있습니다.

모델을 쉽게 상상할 수없는 경우에는 먼저 모델을 만들어야합니다.

최악의 경우는 일부 프로그래머가 모델을 상상할 수 있다고 생각하는 경우입니다. 중요한 세부 사항, 특수한 경우, 예외 또는 성능 고려 사항을 생략했을 수 있습니다. GUI가 이미 구축되어 있고 생략되는 경우 많은 고려 사항이 있기 때문에 모델이 끔찍합니다.

이것은 실제로 응용 프로그램에 따라 다릅니다.

닫힌 클라이언트 / 서버 응용 프로그램을 구축하는 경우 두 방법 중 하나만 사용하면됩니다. 프런트 엔드 요구 사항에 맞게 백 엔드를 조작 할 때는 필연적으로 필요합니다.

잠재적 인 웹 서비스가 고객이 사용할 수 있도록 공개 클라이언트 / 서버 응용 프로그램을 구축하는 경우 고객이 해당 서비스를 사용하여 프런트 엔드를 개발할 수있는 방법을 알고 있어야합니다.

개발의 작은 반복 사이클 (Scrum, Kanban 등)의 푸시와 관련하여 종종 늦게 프런트 엔드와 백 엔드가 병렬로 수행됩니다. 주어진 반복에 필요한 것을 제공하는 것입니다. 우리가 접근 할 필요가있는 경우 빌드를 무시합니다 . 병렬 접근 방식에서 개발 및 개발 과정에서 양 끝은 훨씬 더 가깝게 유지되므로 프런트 엔드와 백 엔드가 병합 될 때 지속적인 변경이 필요하지 않습니다. 이것이 가능할 때 내가 선호하는 접근법입니다.

당신은 언급 ...

... WPF에는 가능한 동적 바인딩 기능이 있습니다. 그러나 한계가 있습니다. 필연적으로 도메인 모델에 속하는 일부 코드는 GUI 클래스로 끝납니다 ...

아니 당신이 무슨 뜻인지 몇 가지 ? WPF와 SL은 바인딩 기능으로 유명합니다. 끝이 없습니다. MVVM 기반 WPF 애플리케이션의 View 내에 코드를 배치해야하는 경우 문제를 해결해야합니다. 연결된 동작 은 View 내 이벤트와 관련되지 않고 동작을 구현하는 한 가지 방법이며 View를 깨끗하게 유지하는 다른 많은 방법입니다.

사용자 상호 작용 자세의 프론트 엔드는 백엔드 구현과 관련 이 없어야합니다 . 백엔드 단독 작업은 프론트 엔드에 대한 처리 데이터 또는 기타 수단을 통해 데이터를 제공하는 것입니다. 이는 개발중인 응용 프로그램 유형과 다시 연결됩니다.

소스 코드를 유지 관리 할 수있게하는 것은 실제로 완전히 다른 질문입니다. 높은 수준에서는 다음과 같은 입증 된 패턴, 아키텍처 및 기술과 함께 최상의 코딩 방법과 관련이 있습니다.

고객의 의견을 바탕으로 기본 UI를 먼저 디자인하는 것이 좋습니다 (종이에 있더라도). 고객은 그들이 볼 때까지 원하는 것을 실제로 알지 못할 수도 있습니다. 고객이 말한 내용을 항상 신뢰할 수있는 것은 아닙니다. UI 프로토 타입을 본 후 고객이 원하는 것에 맞지 않는 경우에만 강력한 도메인 모델을 작성하는 데 몇 주를 투자 할 수 있습니다.

우리는 자동화 된 테스트로 소프트웨어를 구동하려고합니다. 자동화 된 UI 테스트는 시간이 많이 소요됩니다. 콘솔에서 일부 값을 확인하는 스크립트가 더 쉽습니다.

이를 염두에두고 비즈니스 로직을 UI와 분리하는 데 매우 신중합니다.

리드 개발자가 한 번이라도 문서 /보기 아키텍처가 UI와 모든 비즈니스 코드 바인딩을 중지해야한다고 제안했을 때 문서 /보기 아키텍처가 쓸모없는 것으로 여겨졌다 고 기억합니다. 문제는 우리의 문제조차 아니었다). 나는 단순히 멍청했다.

IMNSHO, 적어도 비즈니스 대 UI 계층이 없다는 변명은 없습니다. 당신의 제품이 약간의 흥미로운 일을한다면, 코드 분리를 가능하게하기 위해이 분리가 반드시 필요합니다.

C # 개발자로서, 당신이 외부에서 일하는 것에 대해 비둘기 멍청하다고 생각하지 않습니다. 실제로 도메인 모델을 먼저 선호합니다.

WPF의 경우 필자가 설명한 모델의 유일한 단점은 UI와 도메인 모델 사이를 중재해야하는 경우가 있다는 것입니다. 그럼에도 불구하고 때로는 더 많은 작업을 의미하지만 더 깨끗한 코드도 의미합니다.

물론 도메인 우선!

스몰 토크의 장점은 작업 영역이나 인스펙터에서 "인쇄"하는 것을 포함하여 여러 가지 방법으로 도메인 모델을 쉽게 "구동"할 수 있다는 것입니다. 도메인이 원하는대로 작동하고 있다고 확신 할 때만 완벽한 GUI를 만드는 데 집중했습니다.

스몰 토커가 동시에 두 가지 작업을 수행하지는 않았지만 GUI가 비즈니스 논리를 구현하지 못한 경우 일반적으로 GUI에 특별한 경우를 두지 않고 도메인 모델을 먼저 수정했습니다.